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

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

برنج. 1. چهار بخش بین سه کارگزار توزیع شده است

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

خرابی پارتیشن

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

کارگزار 3 شبکه را ترک می کند و یک رهبر جدید برای بخش 2 در کارگزار 2 انتخاب می شود.

برنج. 2. بروکر 3 می میرد و فالوور او در بروکر 2 به عنوان رهبر جدید پارتیشن 2 انتخاب می شود.

سپس کارگزار 1 خارج می شود و بخش 1 نیز رهبر خود را از دست می دهد که نقش آن به کارگزار 2 می رسد.

برنج. 3. یک کارگزار باقی مانده است. همه رهبران روی یک کارگزار با افزونگی صفر هستند

وقتی بروکر 1 دوباره آنلاین می شود، چهار فالوور اضافه می کند و مقداری افزونگی به هر پارتیشن ارائه می دهد. اما همه رهبران همچنان روی کارگزار 2 باقی ماندند.

برنج. 4. رهبران روی کارگزار 2 باقی می مانند

وقتی بروکر 3 بالا می آید، ما به سه کپی در هر پارتیشن برمی گردیم. اما همه رهبران هنوز در بروکر 2 هستند.

برنج. 5. قرارگیری نامتعادل لیدرها پس از ترمیم کارگزاران 1 و 3

کافکا ابزاری برای تعادل مجدد رهبر بهتر از RabbitMQ دارد. در آنجا، باید از یک پلاگین یا اسکریپت شخص ثالث استفاده می‌کردید که سیاست‌های مهاجرت گره اصلی را با کاهش افزونگی در حین مهاجرت تغییر می‌داد. علاوه بر این، برای صف های بزرگ مجبور بودیم در حین همگام سازی عدم دسترسی را بپذیریم.

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

برای رفع این مشکل، کافکا دو گزینه ارائه می دهد:

• گزینه auto.leader.rebalance.enable=true به گره کنترل‌کننده اجازه می‌دهد تا به طور خودکار رهبران را به نسخه‌های ترجیحی بازگرداند و در نتیجه توزیع یکنواخت را بازیابی کند.
• مدیر می تواند اسکریپت را اجرا کند kafka-preferred-replica-election.sh برای جابجایی دستی

برنج. 6. کپی پس از تعادل مجدد

این یک نسخه ساده شده از شکست بود، اما واقعیت پیچیده تر است، اگرچه هیچ چیز خیلی پیچیده ای در اینجا وجود ندارد. همه چیز به کپی های همگام شده (In-Sync Replicas، ISR) برمی گردد.

کپی های همگام سازی شده (ISR)

یک ISR مجموعه‌ای از کپی‌های یک پارتیشن است که "همگام" (in-sync) در نظر گرفته می‌شود. رهبر وجود دارد، اما ممکن است پیروانی وجود نداشته باشد. اگر فالوور قبل از انقضای بازه زمانی، از تمام پیام های رهبر کپی دقیقی تهیه کرده باشد، همگام تلقی می شود. replica.lag.time.max.ms.

یک دنبال کننده از مجموعه ISR حذف می شود اگر:

• не сделал запрос на выборку за интервал replica.lag.time.max.ms (مرده درنظر گرفته شده)
• در طول بازه زمانی موفق به به روز رسانی نشد replica.lag.time.max.ms (کند در نظر گرفته می شود)

دنبال کنندگان در بازه زمانی درخواست نمونه گیری می کنند replica.fetch.wait.max.ms، که به طور پیش فرض 500 میلی ثانیه است.

برای توضیح واضح هدف ISR، باید به تأییدیه های سازنده و برخی سناریوهای شکست نگاه کنیم. تولیدکنندگان می توانند انتخاب کنند که چه زمانی کارگزار تأییدیه را ارسال می کند:

• acks=0, подтверждение не отправляется
• acks=1، پس از اینکه رهبر پیامی به گزارش محلی خود نوشت، تأیید ارسال می‌شود
• acks=all, подтверждение отправляется после того, как все реплики в ISR записали сообщение в локальные логи

در اصطلاح کافکا، اگر ISR پیامی را ذخیره کرده باشد، "متعهد" است. Acks=all ایمن ترین گزینه است، اما تاخیر اضافی را نیز اضافه می کند. بیایید به دو مثال از شکست و نحوه تعامل گزینه های مختلف 'acks' با مفهوم ISR نگاه کنیم.

Acks=1 و ISR

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

در این مثال، سازنده مقدار acks=1 را دارد. این بخش در هر سه کارگزار توزیع شده است. بروکر 3 عقب است، هشت ثانیه پیش با لیدر هماهنگ شد و اکنون 7456 پیام عقب است. بروکر 1 تنها یک ثانیه عقب بود. تهیه‌کننده ما پیامی می‌فرستد و به سرعت اکی را دریافت می‌کند، بدون سربار فالوورهای کند یا مرده که رهبر منتظر آن نیست.

برنج. 7. ISR با سه ماکت

Broker 2 از کار می افتد و تولید کننده یک خطای اتصال دریافت می کند. پس از اینکه رهبری به کارگزار 1 می رسد، 123 پیام را از دست می دهیم. دنبال کننده در کارگزار 1 بخشی از ISR بود، اما در هنگام سقوط کاملاً با رهبر هماهنگ نبود.

Рис. 8. При сбое теряются сообщения

در پیکربندی bootstrap.servers سازنده چندین کارگزار را فهرست کرده است و می تواند از کارگزار دیگری بپرسد که رهبر بخش جدید کیست. سپس با کارگزار 1 ارتباط برقرار می کند و به ارسال پیام ادامه می دهد.

برنج. 9. ارسال پیام ها پس از یک استراحت کوتاه از سر گرفته می شود

Broker 3 حتی عقب تر است. درخواست‌های واکشی می‌کند اما نمی‌تواند همگام‌سازی شود. این ممکن است به دلیل اتصال کم شبکه بین کارگزاران، مشکل ذخیره سازی و غیره باشد. از ISR حذف شده است. اکنون ISR از یک ماکت تشکیل شده است - رهبر! سازنده همچنان به ارسال پیام و دریافت تاییدیه ادامه می دهد.

برنج. 10. دنبال کننده در کارگزار 3 از ISR حذف می شود

کارگزار 1 پایین می آید و نقش رهبری به کارگزار 3 می رسد با از دست دادن 15286 پیام! سازنده یک پیام خطای اتصال دریافت می کند. انتقال به یک رهبر خارج از ISR تنها به دلیل تنظیم امکان پذیر بود unclean.leader.election.enable=true. اگر در آن نصب شده باشد غلط، سپس انتقال رخ نمی دهد و همه درخواست های خواندن و نوشتن رد می شوند. در این مورد، ما منتظر می مانیم تا کارگزار 1 با داده های دست نخورده خود در ماکت بازگردد، که دوباره رهبری را به دست می گیرد.

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

Производитель устанавливает соединение с последним брокером и видит, что тот теперь лидер раздела. Он начинает отправлять сообщения брокеру 3.

Рис. 12. После краткого перерыва сообщения снова отправляются в раздел 0

دیدیم که جدا از وقفه های کوتاه برای ایجاد ارتباطات جدید و جستجوی رهبر جدید، سازنده دائماً پیام می فرستاد. این پیکربندی در دسترس بودن را به قیمت ثبات (امنیت داده) تضمین می کند. کافکا هزاران پیام را از دست داد اما به پذیرش نوشته های جدید ادامه داد.

Acks=all و ISR

بیایید دوباره این سناریو را تکرار کنیم، اما با آکس=همه. بروکر 3 دارای تاخیر متوسط ​​چهار ثانیه است. سازنده پیامی با آکس=همه، و اکنون پاسخ سریعی دریافت نمی کند. رهبر منتظر است تا پیام توسط همه نسخه‌های مشابه در ISR ذخیره شود.

برنج. 13. ISR با سه ماکت. یکی کند است و در نتیجه ضبط با تاخیر مواجه می شود

پس از چهار ثانیه تاخیر اضافی، کارگزار 2 یک آک ارسال می کند. همه کپی ها اکنون به طور کامل به روز شده اند.

برنج. 14. همه کپی ها پیام ها را ذخیره و ارسال می کنند

بروکر 3 اکنون بیشتر عقب افتاده و از ISR حذف شده است. تأخیر به طور قابل توجهی کاهش می یابد زیرا هیچ کپی کندی در ISR باقی نمانده است. بروکر 2 اکنون فقط منتظر کارگزار 1 است و میانگین تاخیر او 500 میلی ثانیه است.

برنج. 15. ماکت بروکر 3 از ISR حذف می شود

سپس کارگزار 2 سقوط می کند و رهبری بدون از دست دادن پیام به کارگزار 1 می رسد.

Рис. 16. Брокер 2 падает

سازنده یک رهبر جدید پیدا می کند و شروع به ارسال پیام برای او می کند. تأخیر بیشتر کاهش می یابد زیرا ISR اکنون از یک ماکت تشکیل شده است! بنابراین گزینه آکس=همه افزونگی اضافه نمی کند.

Рис. 17. Реплика на брокере 1 берет на себя лидерство без потери сообщений

سپس بروکر 1 کرش می کند و با از دست دادن 3 پیام به بروکر 14238 می رسد!

Рис. 18. Брокер 1 умирает, а переход лидерства с настройкой unclean приводит к обширной потере данных

ما نتوانستیم گزینه را نصب کنیم ناپاک.رهبر.انتخابات.فعال کردن به معنا درست. به طور پیش فرض برابر است با غلط. Настройка آکس=همه с unclean.leader.election.enable=true با برخی از امنیت داده های اضافی، قابلیت دسترسی را فراهم می کند. اما همانطور که می بینید، ما همچنان می توانیم پیام ها را از دست بدهیم.

اما اگر بخواهیم امنیت داده ها را افزایش دهیم چه؟ می توانید قرار دهید unclean.leader.election.enable = نادرست، اما این لزوماً ما را از از دست دادن داده محافظت نمی کند. اگر رهبر به سختی سقوط کرد و داده ها را با خود برد، پیام ها همچنان از بین می روند، به علاوه در دسترس بودن از بین می رود تا زمانی که مدیر وضعیت را بازیابی کند.

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

Acks=all، min.insync.replicas و ISR

با پیکربندی موضوع min.insync.replicas мы повышаем уровень безопасности данных. Давайте еще раз пройдемся по последней части прошлого сценария, но на этот раз с min.insync.replicas=2.

بنابراین بروکر 2 دارای یک ماکت رهبر است و دنبال کننده روی کارگزار 3 از ISR حذف می شود.

برنج. 19. ISR از دو ماکت

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

برنج. 20. تعداد ISR ها یک عدد کمتر از مقدار مشخص شده در min.insync.replicas است.

این پیکربندی در دسترس بودن را فدای ثبات می کند. قبل از تأیید یک پیام، اطمینان حاصل می کنیم که حداقل در دو نسخه تکراری نوشته شده است. این به سازنده اطمینان بسیار بیشتری می دهد. در اینجا، از دست دادن پیام تنها در صورتی امکان‌پذیر است که دو نسخه تکراری به طور همزمان در یک بازه زمانی کوتاه تا زمانی که پیام به یک دنبال‌کننده دیگر تکرار شود، شکست بخورند، که بعید است. اما اگر فوق پارانوئید هستید، می توانید ضریب تکرار را روی 5 تنظیم کنید و min.insync.replicas توسط 3. در اینجا سه ​​کارگزار باید به طور همزمان سقوط کنند تا رکورد را از دست بدهند! البته، شما برای این قابلیت اطمینان با تاخیر اضافی هزینه می کنید.

زمانی که دسترسی برای امنیت داده ها ضروری است

همانطور که در مورد با RabbitMQ، گاهی اوقات دسترسی برای امنیت داده ها ضروری است. در اینجا چیزی است که باید در مورد آن فکر کنید:

• آیا ناشر می تواند به سادگی یک خطا را برگرداند و از سرویس بالادستی یا کاربر بخواهد بعداً دوباره امتحان کند؟
• آیا ناشر می تواند پیام را به صورت محلی یا در پایگاه داده ذخیره کند تا بعداً دوباره امتحان کند؟

Если ответ отрицательный, то оптимизация доступности повышает безопасность данных. Вы потеряете меньше данных, если выберете доступность вместо отказа от записи. Таким образом, все сводится к поиску баланса, а решение зависит от конкретной ситуации.

معنی ISR

مجموعه ISR به شما امکان می دهد تعادل بهینه بین امنیت داده و تأخیر را انتخاب کنید. به عنوان مثال، در صورت خرابی اکثر نسخه‌ها از در دسترس بودن اطمینان حاصل کنید، و تأثیر کپی‌های مرده یا کند را از نظر تأخیر به حداقل برسانید.

معنی را خودمان انتخاب می کنیم replica.lag.time.max.ms با توجه به نیاز شما اساساً، این پارامتر به این معنی است که ما حاضریم چه مقدار تاخیر را بپذیریم آکس=همه. مقدار پیش فرض ده ثانیه است. اگر این مدت برای شما طولانی است، می توانید آن را کاهش دهید. سپس فراوانی تغییرات در ISR افزایش می یابد، زیرا دنبال کنندگان بیشتر حذف و اضافه می شوند.

В RabbitMQ просто набор зеркал, которые нужно реплицировать. Медленные зеркала привносят дополнительную задержку, а отклика мертвых зеркал можно ждать до истечения времени жизни пакетов, которые проверяют доступность каждого узла (net tick). ISR — интересный способ избежать этих проблем с увеличением задержки. Но мы рискуем потерять избыточность, поскольку ISR может сократиться только до лидера. Чтобы избежать этого риска, используйте настройку min.insync.replicas.

تضمین اتصال مشتری

در تنظیمات bootstrap.servers تولید کننده و مصرف کننده می توانند کارگزارهای متعددی را برای اتصال مشتریان مشخص کنند. ایده این است که وقتی یک گره پایین می‌آید، چندین گره اضافی باقی می‌ماند که مشتری می‌تواند با آن یک اتصال را باز کند. اینها لزوماً رهبران بخش نیستند، بلکه صرفاً یک سکوی پرشی برای بارگذاری اولیه هستند. مشتری می تواند از آنها بپرسد که کدام گره میزبان رهبر پارتیشن خواندن/نوشتن است.

В RabbitMQ клиенты могут подключаться к любому узлу, а внутренняя маршрутизация отправляет запрос куда надо. Это означает, что вы можете установить перед RabbitMQ балансировщик нагрузки. Kafka требует, чтобы клиенты подключались к узлу, на котором размещается лидер соответствующего раздела. В такой ситуации балансировщик нагрузки не поставить. Список bootstrap.servers критически важен, чтобы клиенты могли обращаться к нужным узлам и находить их после сбоя.

معماری اجماع کافکا

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

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

Zookeeper хранит состояние кластера:

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

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

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

برای هر بخش کنترل کننده:

• به روز رسانی اطلاعات در Zookeeper در مورد ISR و رهبر.
• یک LeaderAndISRCommand را برای هر کارگزاری که یک نسخه از این پارتیشن را میزبانی می کند ارسال می کند و کارگزاران را در مورد ISR و رهبر مطلع می کند.

هنگامی که یک کارگزار با یک رهبر سقوط می کند، Zookeeper یک اعلان به کنترل کننده می فرستد و او یک رهبر جدید را انتخاب می کند. مجدداً، کنترل‌کننده ابتدا Zookeeper را به‌روزرسانی می‌کند و سپس فرمانی را برای هر کارگزاری ارسال می‌کند و آنها را از تغییر رهبری مطلع می‌کند.

هر رهبر مسئول استخدام ISR است. تنظیمات replica.lag.time.max.ms تعیین می کند که چه کسی وارد آنجا می شود. هنگامی که ISR تغییر می کند، رهبر اطلاعات جدید را به Zookeeper منتقل می کند.

Zookeeper همیشه از هرگونه تغییر مطلع می شود تا در صورت شکست، مدیریت به آرامی به یک رهبر جدید منتقل شود.

برنج. 21. اجماع کافکا

پروتکل تکرار

درک جزئیات تکرار به شما کمک می کند تا سناریوهای بالقوه از دست دادن داده را بهتر درک کنید.

پرس و جوهای نمونه برداری، Log End Offset (LEO) و Highwater Mark (HW)

ما در نظر گرفتیم که دنبال کنندگان به صورت دوره ای درخواست های واکشی را برای رهبر ارسال می کنند. فاصله پیش فرض 500 میلی ثانیه است. این تفاوت با RabbitMQ در این است که در RabbitMQ تکرار توسط آینه صف آغاز نمی شود، بلکه توسط master آغاز می شود. استاد تغییرات را به آینه ها فشار می دهد.

رهبر و همه دنبال کنندگان برچسب Log End Offset (LEO) و Highwater (HW) را ذخیره می کنند. علامت LEO افست آخرین پیام را در ماکت محلی ذخیره می کند و HW آفست آخرین commit را نگه می دارد. به یاد داشته باشید که برای وضعیت commit، پیام باید در تمام کپی‌های ISR باقی بماند. این بدان معنی است که LEO معمولاً کمی جلوتر از HW است.

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

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

شکست رهبر

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

1. Усечёт локальный лог до известного HW и отправит новому лидеру запрос на сообщения после этой отметки.
2. درخواستی را برای رهبر ارسال می‌کند تا HW را در زمانی که به عنوان رهبر انتخاب شده است، بیابد و سپس گزارش را به این افست کوتاه کند. سپس شروع به ایجاد درخواست های واکشی دوره ای با شروع این افست می کند.

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

• هنگامی که یک رهبر شکست می خورد، اولین دنبال کننده در مجموعه ISR که در Zookeeper ثبت شده است، در انتخابات برنده می شود و رهبر می شود. همه دنبال‌کنندگان در ISR، اگرچه «همگام» در نظر گرفته می‌شوند، ممکن است نسخه‌ای از همه پیام‌ها را از رهبر سابق دریافت نکرده باشند. این کاملاً ممکن است که فالوور مشخص شده به روزترین نسخه را نداشته باشد. کافکا تضمین می کند که هیچ گونه واگرایی بین ماکت ها وجود ندارد. بنابراین، برای جلوگیری از اختلاف، هر پیرو باید گزارش خود را به مقدار HW رهبر جدید در زمان انتخابش کوتاه کند. این یکی دیگر از دلایل تنظیم است آکس=همه برای ثبات بسیار مهم است.
• Сообщения периодически записываются на диск. Если все узлы кластера отказали одновременно, то на дисках сохранятся реплики с разным смещением. Вполне возможно, что когда брокеры снова вернутся в сеть, новый лидер, который будет избран, окажется позади своих фолловеров, потому что он сохранился на диск раньше других.

اتحاد مجدد با خوشه

هنگام پیوستن مجدد به خوشه، کپی‌ها مانند زمانی که یک رهبر شکست می‌خورد، عمل می‌کنند: ماکت رهبر را بررسی می‌کنند و گزارش خود را به HW آن (در زمان انتخاب) کوتاه می‌کنند. در مقایسه، RabbitMQ به همان اندازه گره‌های متحد شده را کاملاً جدید در نظر می‌گیرد. در هر دو مورد، کارگزار هر حالت موجود را کنار می گذارد. اگر از همگام‌سازی خودکار استفاده می‌شود، استاد باید کاملاً تمام محتوای فعلی را به روش «بگذارید کل جهان منتظر بماند» در آینه جدید تکرار کند. استاد هیچ گونه عملیات خواندن یا نوشتن را در طول این عملیات نمی پذیرد. این رویکرد مشکلاتی را در صف های بزرگ ایجاد می کند.

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

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

از دست دادن اتصال

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

در زیر چندین سناریو خرابی اتصال آورده شده است:

• سناریو 1: دنبال کننده رهبر را نمی بیند، اما همچنان نگهبان باغ وحش را می بیند.
• سناریو 2: رهبر هیچ دنبال کننده ای نمی بیند، اما همچنان Zookeeper را می بیند.
• Сценарий 3. Фолловер видит лидера, но не видит Zookeeper.
• سناریوی 4. رهبر پیروان را می بیند، اما نگهبان باغ وحش را نمی بیند.
• سناریوی 5: فالوور از هر دو گره کافکا و Zookeeper کاملا جدا است.
• سناریوی 6: لیدر از هر دو گره کافکا و Zookeeper کاملا جدا است.
• سناریوی 7: گره کنترل کننده کافکا نمی تواند گره کافکا دیگری را ببیند.
• سناریوی 8: کنترل کننده کافکا Zookeeper را نمی بیند.

هر سناریو رفتار خاص خود را دارد.

سناریو 1: دنبال کننده رهبر را نمی بیند، اما همچنان Zookeeper را می بیند

برنج. 22. سناریوی 1: ISR سه ماکت

خرابی اتصال، کارگزار 3 را از کارگزاران 1 و 2 جدا می کند، اما از Zookeeper نه. بروکر 3 دیگر نمی تواند درخواست های واکشی ارسال کند. بعد از گذشت زمان replica.lag.time.max.ms از ISR حذف می شود و در تعهدات پیام شرکت نمی کند. پس از بازیابی اتصال، درخواست‌ها را از سر می‌گیرد و هنگامی که به رهبر رسید، به ISR می‌پیوندد. Zookeeper به دریافت پینگ ها ادامه می دهد و فرض می کند که کارگزار زنده و سالم است.

برنج. 23. سناریوی 1: اگر در بازه replica.lag.time.max.ms درخواست واکشی از طرف کارگزار دریافت نشود، کارگزار از ISR حذف می شود.

هیچ تعلیق مغزی یا گره‌ای مانند RabbitMQ وجود ندارد. در عوض، افزونگی کاهش می یابد.

سناریو 2: لیدر هیچ دنبال کننده ای نمی بیند، اما همچنان Zookeeper را می بیند

برنج. 24. سناریو 2. رهبر و دو پیرو

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

برنج. 25. سناریوی 2. ISR فقط به رهبر کوچک شده است

سناریو 3. پیرو رهبر را می بیند، اما نگهبان باغ وحش را نمی بیند

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

Рис. 26. Сценарий 3. Фолловер продолжает отправлять лидеру запросы на выборку

سناریوی 4. رهبر پیروان را می بیند، اما Zookeeper را نمی بیند

برنج. 27. سناریو 4. رهبر و دو پیرو

رهبر از Zookeeper جدا شده است، اما نه از دلالان دارای فالوور.

برنج. 28. سناریوی 4: جدا شدن رهبر از Zookeeper

پس از مدتی، Zookeeper خرابی کارگزار را ثبت می کند و کنترل کننده را در مورد آن مطلع می کند. او رهبر جدیدی را از میان پیروان خود انتخاب خواهد کرد. با این حال، رهبر اصلی همچنان فکر می کند که رهبر است و به پذیرش ورودی ها ادامه می دهد آکس=1. Фолловеры больше не отправляют ему запросы на выборку, поэтому он посчитает их мертвыми и попытаться сжать ISR до самого себя. Но поскольку у него нет подключения к Zookeeper, он не сможет это сделать, и в этот момент откажется от дальнейшего приема записей.

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

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

برنج. 29. سناریوی 4. رهبر بروکر 1 پس از بازیابی شبکه به یک فالوور تبدیل می شود.

سناریوی 5: فالوور از هر دو گره کافکا و Zookeeper کاملا جدا است

Фолловер полностью изолирован и от других узлов Kafka, и от Zookeeper. Он просто удаляется из ISR, пока сеть не восстановится, а потом догоняет остальных.

برنج. 30. سناریوی 5: دنبال کننده ایزوله از ISR حذف می شود

Сценарий 6. Лидер полностью отделен и от других узлов Kafka, и от Zookeeper

برنج. 31. سناریو 6. رهبر و دو پیرو

رهبر کاملاً از پیروان خود، کنترل کننده و نگهبان باغ وحش جدا شده است. برای مدت کوتاهی به پذیرش ورودی‌ها ادامه خواهد داد آکس=1.

برنج. 32. سناریوی 6: جداسازی رهبر از سایر گره های کافکا و باغ وحش

عدم دریافت درخواست پس از انقضا replica.lag.time.max.ms, он попытается сжать ISR до самого себя, но не сможет этого сделать, поскольку нет связи с Zookeeper, тогда он прекратит принимать записи.

در همین حال، Zookeeper کارگزار جدا شده را به عنوان مرده علامت گذاری می کند و کنترل کننده یک رهبر جدید را انتخاب می کند.

برنج. 33. سناریوی 6. دو رهبر

Исходный лидер может принимать записи в течение нескольких секунд, но затем перестает принимать любые сообщения. Клиенты обновляются каждые 60 секунд с последними метаданными. Они будут проинформированы о смене лидера и начнут отправлять записи новому лидеру.

برنج. 34. سناریوی 6: تولیدکنندگان به یک رهبر جدید روی می آورند

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

برنج. 35. سناریوی 6: رهبر اصلی پس از بازیابی اتصال به شبکه، یک فالوور می شود

В этой ситуации в течение короткого периода может наблюдаться логическое разделение, но только если آکس=1 и min.insync.replicas тоже 1. Логическое разделение автоматически завершается либо после восстановления сети, когда исходный лидер понимает, что он больше не лидер, либо когда все клиенты понимают, что лидер изменился и начинают писать новому лидеру — в зависимости от того, что произойдет раньше. В любом случае произойдет потеря некоторых сообщений, но только с آکس=1.

نوع دیگری از این سناریو وجود دارد که در آن، درست قبل از انشعاب شبکه، پیروان عقب افتادند و رهبر ISR را فقط به خودش فشرده کرد. سپس به دلیل از دست دادن اتصال، ایزوله می شود. یک رهبر جدید انتخاب می شود، اما رهبر اصلی همچنان به پذیرش ورودی ها ادامه می دهد آکس=همه، زیرا جز او هیچ کس دیگری در ISR وجود ندارد. پس از بازیابی شبکه، این رکوردها از بین خواهند رفت. تنها راه اجتناب از این گزینه است min.insync.replicas = 2.

سناریوی 7: گره کنترل کننده کافکا نمی تواند گره کافکا دیگری را ببیند

В целом, после потери связи с узлом Kafka контроллер не сможет передать ему никакой информации по изменению лидера. В худшем случае это приведет к краткосрочному логическому разделению, как в сценарии 6. Чаще всего брокер просто не станет кандидатом на лидерство в случае отказа последнего.

سناریوی 8: کنترل کننده کافکا Zookeeper را نمی بیند

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

نتیجه گیری از سناریوها

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

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

پارامتر min.insync.replicas در دو یا چند نسخه، اطمینان بیشتری را فراهم می‌کند که چنین سناریوهای کوتاه‌مدتی مانند سناریو 6 منجر به پیام‌های از دست رفته نمی‌شوند.

خلاصه ای از پیام های گمشده

بیایید تمام راه هایی را که می توانید داده ها را در کافکا از دست بدهید فهرست کنیم:

• هر گونه شکست رهبر در صورت تایید پیام ها با استفاده از آکس=1
• هرگونه انتقال ناپاک رهبری، یعنی به پیروان خارج از ISR، حتی با آکس=همه
• جداسازی رهبر از Zookeeper در صورت تأیید پیام‌ها با استفاده از آن آکس=1
• انزوای کامل رهبر که قبلاً گروه ISR را به خود کوچک کرده است. حتی همه پیام ها از بین خواهند رفت آکس=همه. این تنها در صورتی صادق است که min.insync.replicas=1.
• خرابی همزمان تمام گره های پارتیشن. از آنجایی که پیام‌ها از حافظه تأیید می‌شوند، ممکن است برخی هنوز روی دیسک نوشته نشده باشند. پس از راه اندازی مجدد سرورها، ممکن است برخی از پیام ها گم شده باشند.

از انتقال ناخالص رهبری می توان با ممنوع کردن آنها و یا اطمینان از حداقل دو مورد تعدیل اجتناب کرد. بادوام ترین پیکربندی ترکیبی است آکس=همه и min.insync.replicas بیش از 1

مقایسه مستقیم پایایی RabbitMQ و Kafka

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

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

وقتی چندین سرور در یک خوشه همزمان از کار بیفتند، RabbitMQ از نظر قابلیت اطمینان از کافکا برتر است. همانطور که قبلاً گفتیم، RabbitMQ تنها پس از اینکه پیام توسط master و همه آینه‌ها روی دیسک نوشته شد، تأییدیه را برای ناشر ارسال می‌کند. اما این به دو دلیل تاخیر اضافی را اضافه می کند:

• fsync هر چند صد میلی ثانیه
• Сбой зеркала могут заметить только по истечении времени жизни пакетов, которые проверяют доступность каждого узла (net tick). Если зеркало тормозит или упало, это добавляет задержку.

شرط کافکا این است که اگر یک پیام در چندین گره ذخیره شود، می‌تواند پیام‌ها را به محض اینکه به حافظه رسید، تأیید کند. به همین دلیل، خطر از دست دادن پیام ها از هر نوع (حتی آکس=همه, min.insync.replicas=2) در صورت خرابی همزمان.

به طور کلی، کافکا عملکرد نرم‌افزاری بهتری از خود نشان می‌دهد و از ابتدا برای خوشه‌ها طراحی شده است. در صورت لزوم می توان تعداد فالوورها را برای اطمینان به 11 نفر افزایش داد. ضریب تکرار 5 و حداقل تعداد ماکت در همگام سازی min.insync.replicas=3 از دست دادن پیام به یک رویداد بسیار نادر تبدیل خواهد شد. اگر زیرساخت شما می تواند از این نسبت تکرار و سطح افزونگی پشتیبانی کند، می توانید این گزینه را انتخاب کنید.

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

یکی از پادزهرهای آسیب‌پذیری RabbitMQ در برابر صف‌های بزرگ، شکستن آنها به صف‌های کوچک‌تر است. اگر به سفارش کامل کل صف نیاز ندارید، بلکه فقط به پیام‌های مربوطه (مثلاً پیام‌های یک مشتری خاص)، یا اصلاً چیزی سفارش نمی‌دهید، این گزینه قابل قبول است: به پروژه من نگاه کنید. Rebalanser برای تقسیم صف (پروژه هنوز در مرحله اولیه است).

در نهایت، تعدادی از باگ ها را در مکانیسم های خوشه بندی و تکثیر RabbitMQ و Kafka فراموش نکنید. با گذشت زمان، سیستم‌ها بالغ‌تر و پایدارتر شده‌اند، اما هیچ پیامی هرگز از دست دادن 100% در امان نخواهد بود! علاوه بر این، تصادفات بزرگ در مراکز داده رخ می دهد!

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

اغلب از من می پرسند: "چه چیزی را انتخاب کنم، کافکا یا RabbitMQ؟"، "کدام پلت فرم بهتر است؟". حقیقت این است که واقعاً به موقعیت شما، تجربه فعلی و غیره بستگی دارد. من در بیان نظر خود مردد هستم زیرا توصیه یک پلتفرم برای همه موارد استفاده و محدودیت‌های احتمالی بسیار ساده‌تر از حد است. این سری مقالات را نوشتم تا شما هم نظر خود را بنویسید.

من می خواهم بگویم که هر دو سیستم در این زمینه پیشرو هستند. من ممکن است کمی مغرضانه باشم زیرا از تجربه خود در پروژه ها تمایل دارم به چیزهایی مانند سفارش تضمین شده پیام و قابلیت اطمینان اهمیت بدهم.

من فناوری های دیگری را می بینم که فاقد این قابلیت اطمینان و سفارش تضمین شده هستند، سپس به RabbitMQ و Kafka نگاه می کنم و ارزش باورنکردنی هر دوی این سیستم ها را درک می کنم.

منبع: www.habr.com