بهینه سازی پیکربندی کارگزار کافکا

به دنبال پست های محبوب و همیشه سبز ما در مورد تولید کنندگان و مصرف کنندگان تنظیم دقیق ، ما سه گانه بهینه سازی Kafka خود را با این پست در مورد شروع کار با پیکربندی کارگزار تکمیل می کنیم.

از نظر گزینه هایی که می توانید برای پیکربندی کارگزاران خود استفاده کنید ، مجوزهای بی شماری وجود دارد. ما گزینه ها را کاهش داده و تصفیه کرده ایم و در اینجا آنچه را که معمولاً پیکربندی شده است برای استفاده بیشتر از کارگزاران کافکا ارائه می دهیم.

و وقتی می گوییم کارگزاران ، ما نیز موضوعات را در بر می گیریم. برخی از گزینه های کارگزار پیش فرض هایی را ارائه می دهند که می توانند در سطح موضوع نادیده بگیرند ، مانند تنظیم حداکثر اندازه دسته ای برای موضوعات با پیام. max. bytes.

پیکربندی کارگزار اصلی

یک پیکربندی کارگزار اساسی ممکن است چیزی شبیه به این باشد. تنظیمات موضوعات ، موضوعات و سیاهههای مربوط را مشاهده خواهید کرد.

در Strimzi ، شما این تنظیمات را از طریق ویژگی پیکربندی منبع سفارشی Kafka پیکربندی می کنید.

در این پست ، ما پیشنهاد می کنیم چه چیز دیگری را برای بهینه سازی کارگزاران Kafka خود اضافه کنید. در جایی که مقادیر مثال برای خواص نشان داده شده است ، این معمولاً پیش فرض است - بر اساس آن تنظیم کنید.

برخی از خصوصیات به طور مستقیم توسط استیمزی ، مانند کارگزار. id اداره می شوند. در صورت اضافه شدن به مشخصات پیکربندی ، این خصوصیات نادیده گرفته می شوند.

تکرار موضوعات برای در دسترس بودن بالا

هنگامی که مباحث را پیکربندی می کنید ، تعداد پارتیشن ها ، حداقل تعداد ماکت های همگام سازی و فاکتور تکثیر پارتیشن به طور معمول در سطح موضوع تعیین می شود. برای انجام این کار می توانید از کافکاتوپیک Strimzi استفاده کنید. همچنین می توانید این خصوصیات را در سطح کارگزار نیز تنظیم کنید. در این صورت ، پیش فرض ها برای موضوعاتی اعمال می شود که این خصوصیات را به صراحت تنظیم نمی کنند ، از جمله موضوعات ایجاد شده به صورت خودکار.

محیط های در دسترس بودن بالا نیاز به یک عامل تکثیر حداقل 3 برای موضوعات و حداقل تعداد ماکت های همگام به عنوان 1 کمتر از ضریب تکثیر دارند. برای افزایش دوام داده ، Min. Insync. Replicas را در پیکربندی موضوع و تأیید پیام های تحویل پیام با استفاده از ACK = همه در پیکربندی تولید کننده خود تنظیم کنید.

از ویژگی replic. fetch. max. bytes استفاده کنید تا حداکثر اندازه پیام های دریافت شده توسط هر پیروان را که داده ها را از یک پارتیشن رهبر تکرار می کند ، تعیین کنید. مقدار را در اندازه و توان متوسط پیام پایه قرار دهید. هنگام در نظر گرفتن تخصیص کل حافظه مورد نیاز برای بافر خواندن/نوشتن ، حافظه موجود نیز باید در هنگام ضرب توسط همه پیروان ، حداکثر اندازه پیام تکرار شده را در خود جای دهد.

اهمیت مکانیسم تکثیر موضوع کافکا را نمی توان بیش از حد مورد توجه قرار داد. تکثیر موضوع برای قابلیت اطمینان و دوام داده کافکا اساسی است. با استفاده از تکثیر ، یک کارگزار شکست خورده می تواند از ماکت های همگام در سایر کارگزاران بهبود یابد. ما هنگام بحث در مورد تعادل مجدد پارتیشن برای در دسترس بودن ، به جزئیات بیشتری در مورد رهبران ، پیروان و ماکت های همگام می پردازیم.

ایجاد و حذف مباحث

ویژگی Auto. Create. Topics. Enable به طور پیش فرض فعال می شود به طوری که مباحث در صورت نیاز توسط یک تولید کننده یا مصرف کننده ایجاد می شوند. معمولاً در تولید غیرفعال است زیرا کاربران کافکا تمایل دارند کنترل بیشتری را در مورد ایجاد موضوع اعمال کنند. اگر از ایجاد موضوع اتوماتیک استفاده می کنید ، می توانید تعداد پیش فرض پارتیشن ها را برای موضوعات با استفاده از num. partitions تنظیم کنید. از آن با ویژگی Default. Replication. Factor استفاده کنید. در این حالت ، شما ممکن است بخواهید ضریب تکرار را حداقل سه ماکت تنظیم کنید تا داده ها به طور پیش فرض دوام داشته باشند.

ویژگی Delete. Topic. Enable به طور پیش فرض فعال می شود تا مباحث حذف شود. کاربران کافکا به طور معمول این ملک را در تولید نیز غیرفعال می کنند. این بار مطمئن می شوید که داده ها به طور تصادفی از بین نمی روند ، اگرچه می توانید در صورت نیاز به شرایط ، موقتاً ملک را حذف کنید تا موضوعات را حذف کند.

اگر ویژگی Delete. Topic. Enable روی کاذب تنظیم شده باشد ، نمی توانید موضوعات را با منبع کافکاتوپیک حذف کنید.

تنظیمات موضوع داخلی برای معاملات و تعهدات

به الزامات پیکربندی موضوعات داخلی کافکا توجه کنید.

اگر از معاملات برای فعال کردن نوشتن اتمی به پارتیشن های تولید کنندگان استفاده می کنید ، موضوع داخلی __transaction_state مورد استفاده در این فرآیند به حداقل سه واسطه با تنظیمات پیش فرض نیاز دارد.

موضوع __consumer_offsets ، که تعهدات جبران پارتیشن را ذخیره می کند ، دارای تنظیمات پیش فرض برای تعداد پارتیشن ها و عامل تکثیر است.

هشدار: این تنظیمات را در تولید کاهش ندهید.

با افزایش موضوعات I/O بهبود توان رسیدگی درخواست

موضوعات شبکه (num.network. threads) درخواست ها را به خوشه کافکا ، مانند تولید و درخواست های واکشی از برنامه های مشتری می پردازند. تعداد موضوعات شبکه را تنظیم کنید تا فاکتور تکثیر و سطح فعالیت تولید کنندگان مشتری و مصرف کنندگان در تعامل با خوشه کافکا را منعکس کند. برای کاهش احتقان و تنظیم ترافیک درخواست ، می توانید از queued. max. requests برای محدود کردن تعداد درخواست های مجاز در صف درخواست قبل از مسدود شدن موضوع شبکه استفاده کنید.

معیارهای کارگزار Kafka می توانند در کار با تعداد موضوعات مورد نیاز کمک کنند. به عنوان مثال ، معیارهای مربوط به میانگین موضوعات شبکه زمانی بیکار هستند (kafka.network: type=socketserver ، name=networkprocessoravgidlepercent) درصد منابع مورد استفاده را نشان می دهد. اگر 0 ٪ زمان بیکار باشد ، تمام منابع در حال استفاده هستند ، به این معنی که موضوعات بیشتر می توانند سودمند باشند.

موضوعات I/O (num.io. threads) برای پردازش آنها درخواست هایی را از صف درخواست انتخاب کنید. اضافه کردن موضوعات بیشتر می تواند توان را بهبود بخشد ، اما تعداد هسته های CPU و پهنای باند دیسک یک حد بالایی عملی را تحمیل می کند. یک نقطه شروع خوب ممکن است با پیش فرض 8 ضرب شده توسط تعداد دیسک ها باشد.

برای مشخص کردن تعداد موضوعات مورد استفاده برای بارگذاری ورود به سیستم در راه اندازی و شستشوی در هنگام خاموش کردن ، از num. recovery. threads. per. data. dir استفاده کنید.

به روزرسانی های پیکربندی در استخرهای نخ برای همه کارگزاران ممکن است به صورت پویا در سطح خوشه اتفاق بیفتد. این به روزرسانی ها بین نیمی از اندازه فعلی و دو برابر اندازه فعلی محدود می شوند.

اگر موضوعات به دلیل تعداد دیسک ها آهسته یا محدود هستند ، سعی کنید اندازه بافر برای درخواست های شبکه را برای بهبود توان افزایش دهید:

و همچنین حداکثر تعداد بایت ها را افزایش می دهد kafka می تواند دریافت کند:

افزایش توان برای اتصالات تأخیر بالا

اگر اندازه دسته های پیام خود را تنظیم کرده باشید ، مقادیر پیش فرض بافر برای ارسال و دریافت پیام ممکن است برای توان لازم بسیار کوچک باشد.

اگر می خواهید مقادیر را تغییر دهید ، می توانید با استفاده از محاسبه محصول و تأخیر پهنای باند ، اندازه بهینه بافر خود را انجام دهید. برای کار با آنها به برخی از ارقام نیاز دارید. در اصل ، شما می خواهید ظرفیت پهنای باند خود را با تأخیر در سفر دور بزنید تا حجم داده ها ارائه شود. به این تعریف ویکی نگاه کنید تا نمونه هایی از محاسبه را ببینید.

مدیریت سیاهههای مربوط به سیاست های حفظ داده

کافکا برای ذخیره اطلاعات پیام از سیاههها استفاده می کند. سیاههها مجموعه ای از بخش ها با شاخص های مختلف مرتبط هستند. پیام های جدید به یک بخش فعال واحد نوشته شده است. پیام ها هرگز اصلاح نمی شوند.

با استفاده از درخواست های واکشی ، مصرف کنندگان از بخش ها می خوانند. پس از مدتی ، بخش فعال نورد می شود تا فقط خواندنی شود زیرا یک بخش فعال جدید جایگزین آن می شود. بخش های قدیمی تا زمانی که واجد شرایط حذف باشند ، حفظ می شوند.

می توانید حداکثر اندازه را در بایت های یک بخش ورود به سیستم و مقدار زمان در میلی ثانیه قبل از نورد یک قطعه فعال پیکربندی کنید. آنها را در سطح موضوع با استفاده از Segment. Bytes و Segment. ms تنظیم کنید. یا پیش فرض را در سطح کارگزار برای هر موضوعی که این تنظیمات را ندارند تنظیم کنید:

اندازه های بزرگتر بدان معنی است که بخش فعال حاوی پیام های بیشتری است و در اغلب موارد نورد می شود. بخش های غیر فعال نیز کمتر برای حذف واجد شرایط می شوند.

شما می توانید در رابطه با سیاست های پاکسازی که در مرحله بعد پوشش می دهیم ، سیاست های نگهدارنده ورود به سیستم مبتنی بر زمان یا اندازه را تنظیم کنید ، به طوری که سیاههها قابل کنترل هستند. بخش های ورود به سیستم غیر فعال هنگام رسیدن به محدودیت های احتباس حذف می شوند. با کنترل اندازه ورود به سیستم که حفظ می کنید ، می توانید اطمینان حاصل کنید که احتمالاً از ظرفیت دیسک فراتر نمی روید.

برای حفظ ورود به سیستم مبتنی بر زمان ، از پیکربندی Milliseconds استفاده کنید که در تنظیمات دقیقه و ساعت مربوط به اولویت است. پیکربندی Milliseconds همچنین به صورت پویا به روز می شود ، که تنظیمات دیگر این کار را نمی کند.

دوره نگهداری بر اساس پیام های زمانی است که به این بخش پیوست شده است. اگر log. retention. ms رو ی-1 تنظیم شده باشد ، هیچ محدودیتی برای حفظ ورود به سیستم اعمال نمی شود ، بنابراین تمام سیاههها حفظ می شوند. استفاده از دیسک همیشه باید کنترل شود ، اما تنظی م-1 به طور کلی توصیه نمی شود زیرا به ویژه احتمالاً منجر به مشکلات مربوط به دیسک های کامل می شود ، که اصلاح آن دشوار است.

برای حفظ ورود به سیستم مبتنی بر اندازه ، حداکثر اندازه ورود به سیستم را در بایت تنظیم کنید:

حداکثر اندازه ورود به سیستم برای همه بخش های موجود در سیاهه است. به عبارت دیگر ، یک سیاهه به طور معمول با بخش های تقریباً log. retent. bytes/log. segment. bytes به محض رسیدن به حالت پایدار پایان می یابد. با رسیدن به حداکثر اندازه ورود به سیستم ، بخش های قدیمی تر حذف می شوند.

تنظیم حداکثر اندازه ورود به سیستم در نظر نمی گیرد که پیام های زمانی به یک بخش اضافه شده اند. اگر این یک مسئله بالقوه باشد ، می توانید از حفظ مبتنی بر زمان و اندازه استفاده کنید. هنگامی که از هر دو استفاده می کنید ، آستانه اول به پاکسازی منجر می شود.

اگر می خواهید قبل از حذف یک پرونده بخش از سیستم ، تأخیر زمانی اضافه کنید ، می توانید با استفاده از log. segment. delete. delay. ms برای همه موضوعات در سطح کارگزار یا file. delete. delay. ms تأخیر را اضافه کنید. مباحث در پیکربندی موضوع.

حذف داده های ورود به سیستم با سیاست های پاکسازی

پاک کننده ورود به سیستم کافکا آنچه را که انتظار دارید انجام می دهد. این داده های قدیمی را از ورود به سیستم حذف می کند. به طور پیش فرض فعال شده است (log. cleaner. enable = true) ، می توانید با تعریف یک خط مشی پاکسازی ، کنترل خود را در مورد نحوه عملکرد پاک کننده انجام دهید.

حذف خط مشی خط مشی مطابق با مدیریت سیاهههای مربوط با سیاست های حفظ داده است. مناسب است وقتی داده ها نیازی به حفظ برای همیشه ندارند. بخش های قدیمی بر اساس محدودیت های نگهدارنده ورود به سیستم حذف می شوند. در غیر این صورت ، اگر پاک کننده ورود به سیستم فعال نباشد ، و محدودیت احتباس ورود به سیستم وجود ندارد ، ورود به سیستم همچنان به رشد خود ادامه می دهد.

سیاست جمع و جور جمع و جور برای حفظ جدیدترین پیام برای هر کلید پیام تضمین می کند. وقتی مقادیر پیام قابل تغییر است ، تراکم ورود به سیستم مناسب است و می خواهید آخرین بروزرسانی را حفظ کنید. پیام های جدید به رئیس سیاهه ضمیمه می شوند ، که به همان روشی که یک ورود به سیستم غیر فشرده با Writes Appended به ترتیب انجام می شود ، عمل می کند. در دم یک ورود به سیستم فشرده ، که در آن پاک کننده ورود به سیستم کار می کند ، اگر رکورد دیگری با همان کلید بعداً در ورود به سیستم رخ دهد ، سوابق حذف می شوند. بنابراین ، در حالی که کافکا تضمین می کند که آخرین پیام ها برای هر کلید حفظ می شود ، تضمین نمی کند که کل ورود به سیستم فشرده حاوی نسخه برداری نباشد.

ورود به سیستم قبل از تراکم ، مقدار کلیدی با موقعیت های جبران می نویسد

اگر از کلیدها استفاده نمی کنید ، نمی توانید از تراکم استفاده کنید زیرا کلیدها برای شناسایی پیام های مرتبط مورد نیاز هستند. در حین تمیز کردن ورود به سیستم ، آخرین پیام (با بالاترین جبران) نگه داشته می شود و پیام های قدیمی تر با همان کلید دور ریخته می شوند. سوابق حتی در صورت حذف سوابق اطراف ، جبران های اصلی خود را حفظ می کنند. در نتیجه ، دم می تواند جبران های غیر مبهم داشته باشد. هنگام مصرف یک افست که دیگر در دم موجود نیست ، رکورد با افست بالاتر بعدی یافت می شود.

بعد از تراکم وارد شوید

در صورت عدم وجود بیشترین تعداد کلیدهای مجزا ، سیاههها هنوز هم می توانند با استفاده از تراکم به تنهایی بزرگ شوند. شما می توانید این کار را با تنظیم خط مشی برای جمع و جور و حذف سیاههها کنترل کنید. داده های ورود به سیستم برای اولین بار فشرده شده و سوابق قدیمی تر را که دارای یک کلید در سر ورود هستند ، حذف می کنند. سپس داده هایی که قبل از حذف آستانه نگه داشتن ورود به سیستم حذف می شوند.

نقطه احتباس ورود به سیستم و نقطه تراکم

تنظیم فرکانس ورود به سیستم برای پاکسازی در میلی ثانیه با استفاده از log. retention. check. interval. ms. فرکانس را در تنظیمات نگهدارنده ورود به سیستم پایه گذاری کنید. پاکسازی باید اغلب برای مدیریت فضای دیسک کافی باشد ، اما نه چندان اغلب بر عملکرد یک موضوع تأثیر می گذارد. اندازه های حفظ کوچکتر ممکن است نیاز به بررسی های مکرر داشته باشد. در صورت عدم وجود گزارش برای تمیز کردن برای یک دوره مشخص با استفاده از log. cleaner. backoff. ms ، می توانید تمیز کننده را در حالت آماده به کار قرار دهید.

هنگام حذف تمام پیام های مربوط به یک کلید خاص ، یک تولید کننده یک پیام سنگ قبر را ارسال می کند ، که دارای یک ارزش تهی است و به عنوان یک نشانگر عمل می کند تا به یک مصرف کننده بگوید مقدار حذف شده است. پس از تراکم ، فقط سنگ قبر حفظ می شود ، که باید برای مدت طولانی برای مصرف کننده باشد تا بداند که این پیام حذف شده است. از log. cleaner. delete. retion. ms استفاده کنید تا مطمئن شوید که مصرف کنندگان این فرصت را دارند که قبل از حذف دائمی ، وضعیت نهایی یک رکورد حذف شده را بخوانند. هنگامی که پیام های قدیمی حذف می شوند ، بدون هیچ ارزشی ، کلید Tombstone نیز از پارتیشن حذف می شود.

مدیریت استفاده از دیسک

بسیاری از تنظیمات پیکربندی دیگر در رابطه با پاکسازی ورود به سیستم وجود دارد ، اما از اهمیت ویژه ای برای تخصیص حافظه برخوردار است.

ویژگی deduplication حافظه کل را برای پاکسازی در تمام موضوعات پاک کننده ورود به سیستم مشخص می کند. می توانید حد بالایی را برای درصد حافظه مورد استفاده از طریق ضریب بار بافر تعیین کنید.

هر ورودی ورود به سیستم دقیقاً از 24 بایت استفاده می کند ، بنابراین می توانید چند ورودی ورود به سیستم را بافر بتوانید در یک اجرا انجام داده و تنظیمات را مطابق با آن تنظیم کنید.

در صورت امکان ، اگر به دنبال کاهش زمان تمیز کردن ورود به سیستم هستید ، تعداد موضوعات تمیز کننده ورود به سیستم را در نظر بگیرید:

اگر با استفاده از پهنای باند 100 ٪ دیسک مشکلات را تجربه می کنید ، می توانید پاک کننده ورود به سیستم I/O را گاز بگیرید تا مبلغ عملیات خواندن/نوشتن کمتر از یک مقدار دو برابر مشخص بر اساس قابلیت های دیسک های انجام عملیات باشد:

رسیدگی به اندازه پیام های بزرگ

در حالت ایده آل ، پیام های فردی بیش از چند 100 کیلوبایت نیستند ، و برای تولید بهتر توسط تولید کننده تا حد تنظیم شده توسط پیام. max. bytes (پیکربندی کارگزار) یا max. message. bytes (پیکربندی موضوع) جمع می شوند. این پیش فرض به 1 مگابایت است.

شما چهار روش برای رسیدگی به اندازه پیام های بزرگ دارید:

• فشرده سازی پیام سمت تولید کننده
• پیام رسانی مبتنی بر مرجع
• پیام رسانی درون خطی
• پیکربندی کارگزار و تولید کننده/مصرف کننده

ما توصیه می کنیم فشرده سازی پیام در سمت تولید کننده یا پیام های مبتنی بر مرجع را که بیشتر موقعیت ها را پوشش می دهد ، امتحان کنید.

فشرده سازی سمت تولید کننده

برای فشرده سازی سمت تولید کننده ، شما یک فشرده سازی را مشخص می کنید. نوع مانند GZIP برای استفاده از دسته ها. در پیکربندی کارگزار ، شما از Compression. Type = تولید کننده استفاده می کنید تا کارگزار هر فشاری را که تولید کننده استفاده می کند ، حفظ کند. به طور کلی ، بهتر است که انواع فشرده سازی تولید کننده و موضوع مطابقت داشته باشد. در غیر این صورت ، کارگزار باید قبل از پیوستن به آنها در ورود به سیستم ، دسته ها را فشرده و احتمالاً دوباره بیان کند ، که می تواند CPU فشرده باشد.

فشرده سازی دسته های ، پردازش اضافی را بر روی تولید کننده و فشار بیش از حد بر روی مصرف کننده اضافه می کند. اما داده های بیشتری را در یک دسته دریافت خواهید کرد که به توان آن کمک می کند. همچنین می توانید از فضای ذخیره سازی خود بهتر استفاده کنید. معیارهای خود را بررسی کرده و فشرده سازی سمت تولید کننده را با تنظیم دقیق اندازه دسته ترکیب کنید تا بهترین نتیجه را بدست آورید.

پیام رسانی مبتنی بر مرجع

پیام رسانی مبتنی بر مرجع فقط به داده های ذخیره شده در برخی از سیستم های دیگر در مقدار پیام ارسال می شود. این برای تکثیر داده ها مفید است وقتی نمی دانید پیام چقدر بزرگ خواهد بود. همچنین هنگامی که یک پیام بزرگ گاه به گاه وجود دارد ، خوب کار می کند ، زیرا پیام های کوچکتر می توانند مستقیماً از طریق کافکا ارسال شوند و پیام های بزرگ را می توان با مرجع ارسال کرد. داده ها به فروشگاه داده نوشته شده است ، که باید سریع ، بادوام و بسیار در دسترس باشد و مرجع داده ها بازگردانده می شود. تولید کننده مرجع را به کافکا ارسال می کند. مصرف کننده از مرجع برای واکشی داده ها از فروشگاه داده استفاده می کند.

جریان پیام رسانی مبتنی بر مرجع

ارسال پیام مبتنی بر ارجاع نیاز به سفرهای بیشتری دارد ، بنابراین تأخیر پایان به پایان افزایش می یابد. یکی از اشکال اصلی این رویکرد این است که هنگام تمیز کردن پیام کافکا ، هیچ پاکسازی خودکار از داده ها در سیستم خارجی وجود ندارد. همچنین این خطر وجود دارد که قبل از حذف پیام در کافکا ، داده ها از سیستم خارجی خارج شوند.

یکی از راه های کاهش محدودیت های پیام رسانی مبتنی بر مرجع ، استفاده از رویکرد ترکیبی به طور خلاصه است. پیام های بزرگ را به فروشگاه داده ارسال کرده و پیام های اندازه استاندارد را مستقیماً پردازش کنید.

پیام رسانی درون خطی

پیام رسانی درون خطی یک فرآیند پیچیده است که پیام ها را به تکه هایی که از همان کلید استفاده می کنند ، تقسیم می کند ، که سپس با استفاده از یک پردازنده جریان مانند جریان های کافکا روی خروجی ترکیب می شوند.

مراحل اساسی عبارتند از:

• اگر پیام خیلی بزرگ باشد ، برنامه مشتری تولید کننده سریال می کند و داده ها را بخش می کند.
• تولید کننده قبل از ارسال ، از Bytearryserializer Kafka یا شبیه به سریال سازی مجدد هر قطعه استفاده می کند.
• مصرف کننده پیام ها و تکه های بافرها را تا زمانی که پیام کاملی داشته باشد ردیابی می کند.
• برنامه مشتری مصرف کننده تکه هایی را دریافت می کند ، که قبل از deserialization مونتاژ می شوند.
• پیام های کامل به ترتیب با توجه به جبران اولین یا آخرین قطعه برای هر مجموعه از پیام های خرد شده ، به بقیه برنامه های مصرف کننده تحویل داده می شوند.
• تحویل موفقیت آمیز پیام کامل در برابر ابرداده افست بررسی می شود تا در هنگام تعادل از تکثیر جلوگیری شود.

جریان پیام رسانی درون خطی

پیام رسانی درون خطی به سیستم های خارجی مانند پیام رسانی مبتنی بر مرجع بستگی ندارد. اما به دلیل استفاده از بافر مورد نیاز ، به ویژه در هنگام رسیدگی به یک سری پیام های بزرگ به طور موازی ، عملکرد سربار در سمت مصرف کننده دارد. تکه های پیام های بزرگ می توانند در هم آمیخته شوند ، به طوری که اگر تمام تکه های یک پیام در صورتی که قطعات پیام بزرگ دیگر در بافر ناقص باشد ، همیشه امکان پذیر نیست. به همین دلیل ، بافر معمولاً با ادامه بخش پیام یا اجرای منطق تعهد پشتیبانی می شود.

پیکربندی برای رسیدگی به پیام های بزرگتر

شما با پیکربندی پیام. max. bytes محدودیت پیام را افزایش می دهید تا حداکثر اندازه دسته رکورد را تنظیم کنید. می توانید حد را در سطح موضوع یا سطح کارگزار تنظیم کنید. اگر محدودیت را در سطح کارگزار تعیین کنید ، پیام های بزرگتر برای همه موضوعات و پیام های بزرگتر از حداکثر حد مجاز است. اندازه بافر برای تولید کنندگان (Max. Request. Size) و مصرف کنندگان (Message. Max. Bytes) باید بتوانند پیام های بزرگتر را در خود جای دهند.

کنترل گرگرفتگی داده های پیام

معمولاً آستانه های ورود به سیستم معمولاً تنظیم نشده اند و سیستم عامل با استفاده از تنظیمات پیش فرض خود ، یک پس زمینه را انجام می دهد. اما اگر از مدیریت فلاش برنامه استفاده می کنید ، اگر از دیسک های سریعتر استفاده می کنید ، آستانه های گرگرفتگی پایین ممکن است مناسب باشد.

برای کنترل نوشتن های دوره ای داده های پیام ذخیره شده به دیسک از خصوصیات log flush استفاده کنید. می توانید فرکانس چک های موجود در حافظه نهان را در میلی ثانیه مشخص کنید. فرکانس فلاش را بر اساس حداکثر زمانی که یک پیام در حافظه نگه داشته می شود و حداکثر تعداد پیام های موجود در ورود به سیستم قبل از نوشتن روی دیسک کنترل کنید.

انتظار بین Flushes شامل زمان انجام چک و فاصله مشخص شده قبل از انجام شستشوی است. افزایش فرکانس گرگرفتگی می تواند بر توان تأثیر بگذارد.

پارتیشن مجدد برای در دسترس بودن

هنگام تکرار داده ها در سراسر کارگزاران ، یک رهبر پارتیشن در یک کارگزار همه درخواست های تولید را انجام می دهد (به ورود به سیستم می نویسد). پیروان پارتیشن در سایر کارگزاران داده های پارتیشن رهبر را تکرار می کنند. بنابراین در صورت عدم موفقیت رهبر ، قابلیت اطمینان داده را دریافت می کنید. پیروان برای بهبودی باید همگام باشند ، به این معنی که پیروان با پیام متعهد اخیراً در مورد رهبر روبرو شده اند. اگر یک رهبر دیگر در دسترس نباشد ، یکی از ماکت های درون همزمان به عنوان رهبر جدید انتخاب می شود. رهبر با نگاه به آخرین جبران درخواست شده ، پیروان را بررسی می کند.

در صورت عدم موفقیت رهبر فعلی ، یک پیروان خارج از همگام به عنوان یک رهبر واجد شرایط نیست ، مگر اینکه انتخابات رهبر نجس مجاز باشد.

شما می توانید زمان تاخیر را تنظیم کنید قبل از اینکه یک پیرو از همگام سازی در نظر گرفته شود:

LAG TIME محدودیت بالایی را برای زمان تکرار پیام به همه ماکت های درون همگام سازی و چه مدت یک تولید کننده باید منتظر تصدیق باشد. اگر یک پیرو نتواند درخواست واکشی را انجام دهد و با آخرین پیام در زمان تاخیر مشخص شده ، از ماکت های درون همگام خارج شود. زمانی که استفاده می کنید بستگی به تأخیر شبکه و پهنای باند دیسک کارگزار دارد. می توانید زودتر زمان تاخیر را برای تشخیص ماکت های شکست خورده زودتر کاهش دهید ، اما با این کار احتمال اینکه پیروان را بدون نیاز از همگام خارج کنید ، افزایش می دهید

پیروان فقط برای تکثیر پیام های رهبر پارتیشن کار می کنند و در صورت عدم موفقیت رهبر اجازه می دهند. پیروان به طور معمول به مشتری خدمت نمی کنند ، اگرچه پیکربندی قفسه به مصرف کننده اجازه می دهد تا وقتی یک خوشه کافکا چندین دیتاسنتر را در اختیار دارد ، پیام هایی را از نزدیکترین ماکت مصرف کند.

شما می توانید از Cruise Control برای Strimzi استفاده کنید تا تکالیف ماکت را به کارگزاران بفهمید که بار به طور مساوی در سراسر خوشه تعادل برقرار می کنند. محاسبه آن بار متفاوتی را که توسط رهبران و پیروان تجربه شده است ، در نظر می گیرد. یک رهبر شکست خورده بر تعادل یک خوشه کافکا تأثیر می گذارد زیرا کارگزاران باقیمانده کار اضافی را برای پیشبرد پارتیشن های اضافی دریافت می کنند.

برای تعیین تکلیف که توسط کنترل کروز در واقع متعادل است ، لازم است که پارتیشن ها توسط رهبر ارجح هدایت شوند. کافکا به طور خودکار می تواند اطمینان حاصل کند که از رهبر ترجیحی استفاده می شود (در صورت امکان) ، در صورت لزوم رهبر فعلی را تغییر می دهد. این تضمین می کند که این خوشه در حالت متعادل که توسط کنترل کروز یافت می شود ، باقی بماند.

شما می توانید فرکانس ، در ثانیه ، بررسی های خودکار رهبر را کنترل کنید و حداکثر درصد عدم تعادل مجاز به یک کارگزار قبل از ایجاد مجدد تعادل.

عدم تعادل درصد رهبر برای یک کارگزار ، نسبت بین تعداد فعلی پارتیشن هایی است که کارگزار رهبر فعلی و تعداد پارتیشن هایی است که برای آن رهبر ارجح است. شما می توانید درصد را صفر تنظیم کنید تا اطمینان حاصل شود که رهبران ترجیحی همیشه انتخاب می شوند ، با فرض اینکه آنها همگام هستند.

اگر چک های مربوط به Refalances به کنترل بیشتری نیاز داشته باشد ، می توانید مجوزهای خودکار را غیرفعال کنید. سپس می توانید با استفاده از ابزار خط فرمان Kafka-Leader-Chection. sh ، چه زمانی را برای ایجاد تعادل انتخاب کنید.

داشبورد گرافانا با معیارهای نمایشی Strimzi برای پارتیشن ها و پارتیشن های زیر تکرار شده که رهبر فعال ندارند ، ارائه می دهند.

انتخابات رهبر نجس

انتخاب رهبر به یک ماکت در همگام سازی تمیز تلقی می شود زیرا هیچ ضرر داده را تضمین نمی کند. و این همان چیزی است که به طور پیش فرض اتفاق می افتد. اگر هیچ واسطه ای دیگر در ISR (ماکت در Sync) نبوده است که رهبر قدیمی گم شد ، کافکا منتظر می ماند تا قبل از نوشتن پیام ها یا خواندن پیام ها ، آن رهبر به صورت آنلاین برگردد.

اما اگر هیچ ماکت در همگام سازی برای رهبری وجود نداشته باشد ، چه می شود؟شاید ISR فقط در هنگام فوت دیسک رهبر رهبر را داشته باشد. اگر حداقل تعداد ماکت های همگام تنظیم نشده باشد ، و هیچ پیروان در همگام سازی با رهبر پارتیشن وجود ندارد ، هنگامی که هارد دیسک آن به طور غیرقابل برگشت ناکام باشد ، داده ها از بین می روند. نه تنها این ، بلکه یک رهبر جدید نمی تواند انتخاب شود زیرا هیچ پیروان همگام سازی وجود ندارد.

اگر وضعیت شما از در دسترس بودن بیش از دوام برخوردار باشد ، ممکن است بخواهید انتخابات رهبر نجس را فعال کنید.

انتخابات رهبر نجس به این معنی است که ماکت های خارج از همگام می توانند رهبر شوند ، اما شما خطر از دست دادن پیام ها را دارید.

اجتناب از تعادل گروه های مصرف کننده غیر ضروری

ما با پیشنهاد یک پیکربندی بسیار مفید برای جلوگیری از تغییر مجدد گروه مصرف کننده غیر ضروری ، به این کاوش در نکات تنظیم کارگزار پایان خواهیم داد. می توانید یک تأخیر اضافه کنید تا هماهنگ کننده گروه منتظر بماند تا اعضای قبل از تعادل اولیه بپیوندند:

به ناچار ، یک تجارت وجود دارد زیرا تأخیر مانع از مصرف این گروه تا پایان دوره می شود.

و همانطور که به پایان پست او رسیدیم ، می توانیم در مورد هر تنظیماتی که شما انجام می دهید ، یک نکته کلی بیان کنیم. ایده روشنی در مورد آنچه را که می خواهید با تنظیم خود به دست آورید ، داشته باشید ، اما توجه داشته باشید که برای دستیابی به نتیجه ای که می خواهید ، چه مصالحه ای را برای دستیابی به آن ایجاد می کنید.

نتیجه

به طوری که یک مجموعه هدفمند از متداول ترین گزینه های تنظیم کارگزار را برای بررسی شما تکمیل می کند. آنها را امتحان کنید و پیام های خود را در جریان نگه دارید.