В শেষ প্রবন্ধ আমরা ত্রুটি সহনশীলতা এবং উচ্চ প্রাপ্যতার জন্য RabbitMQ ক্লাস্টারিংয়ের দিকে তাকিয়েছি। এখন অ্যাপাচি কাফকার গভীরে খনন করা যাক।

এখানে প্রতিলিপির একক হল পার্টিশন। প্রতিটি বিষয়ের এক বা একাধিক বিভাগ থাকে। প্রতিটি বিভাগে অনুগামী সহ বা ছাড়া একটি নেতা আছে. একটি বিষয় তৈরি করার সময়, আপনি পার্টিশনের সংখ্যা এবং প্রতিলিপি সহগ উল্লেখ করুন। স্বাভাবিক মান হল 3, যার মানে তিনটি প্রতিলিপি: একজন নেতা এবং দুইজন অনুসারী।

ভাত। 1. তিনটি দালালের মধ্যে চারটি বিভাগ বিতরণ করা হয়

সমস্ত পড়ার এবং লেখার অনুরোধ নেতার কাছে যায়। অনুসরণকারীরা পর্যায়ক্রমে নেতার কাছে সর্বশেষ বার্তা পাওয়ার জন্য অনুরোধ পাঠান। ভোক্তারা কখনই অনুগামীদের দিকে ফিরে যায় না; পরেরটি শুধুমাত্র অপ্রয়োজনীয়তা এবং দোষ সহনশীলতার জন্য বিদ্যমান।

বিভাজন ব্যর্থতা

যখন একজন দালাল ব্যর্থ হয়, তখন অনেক অংশের নেতারা প্রায়ই ব্যর্থ হন। তাদের প্রতিটিতে, অন্য নোড থেকে একজন অনুসারী নেতা হয়ে ওঠে। প্রকৃতপক্ষে, এটি সর্বদা হয় না, যেহেতু সিঙ্ক্রোনাইজেশন ফ্যাক্টরটিও প্রভাবিত করে: সিঙ্ক্রোনাইজড অনুসারী আছে কিনা, এবং যদি না থাকে, তাহলে একটি আনসিঙ্ক্রোনাইজড রেপ্লিকাতে স্যুইচ করা অনুমোদিত কিনা। তবে আসুন আপাতত জিনিসগুলিকে জটিল না করি।

ব্রোকার 3 নেটওয়ার্ক ত্যাগ করে, এবং ব্রোকার 2-এ বিভাগ 2-এর জন্য একজন নতুন নেতা নির্বাচিত হয়।

ভাত। 2. দালাল 3 মারা যায় এবং দালাল 2-এ তার অনুসারী পার্টিশন 2-এর নতুন নেতা নির্বাচিত হয়

তারপর ব্রোকার 1 ত্যাগ করে এবং ধারা 1ও তার নেতাকে হারায়, যার ভূমিকা দালাল 2-এর কাছে চলে যায়।

ভাত। 3. একজন দালাল বাকি আছে। সব নেতা শূন্য অপ্রয়োজনীয় একটি দালালের উপর আছে

যখন ব্রোকার 1 অনলাইনে ফিরে আসে, তখন এটি চারজন অনুসারী যোগ করে, প্রতিটি পার্টিশনে কিছু অপ্রয়োজনীয়তা প্রদান করে। কিন্তু তারপরও সব নেতা দালাল ২-এর ওপর রয়ে গেছেন।

ভাত। 4. নেতারা দালালের উপর রয়ে গেছে 2

যখন ব্রোকার 3 আসে, আমরা প্রতি পার্টিশনে তিনটি প্রতিলিপিতে ফিরে আসি। কিন্তু সব নেতারা এখনো দালাল ২-এর উপর।

ভাত। 5. দালাল 1 এবং 3 পুনরুদ্ধারের পরে নেতাদের ভারসাম্যহীন স্থান নির্ধারণ

কাফকার কাছে RabbitMQ-এর চেয়ে ভাল নেতার ভারসাম্য বজায় রাখার একটি হাতিয়ার রয়েছে। সেখানে, আপনাকে একটি তৃতীয় পক্ষের প্লাগইন বা স্ক্রিপ্ট ব্যবহার করতে হয়েছিল যা মাইগ্রেশনের সময় অপ্রয়োজনীয়তা হ্রাস করে মাস্টার নোড স্থানান্তর করার জন্য নীতিগুলি পরিবর্তন করেছিল। উপরন্তু, বড় সারিগুলির জন্য আমাদের সিঙ্ক্রোনাইজেশনের সময় অনুপলব্ধতা স্বীকার করতে হয়েছিল।

কাফকার নেতৃত্বের ভূমিকার জন্য "পছন্দের প্রতিরূপ" ধারণা রয়েছে। যখন বিষয় পার্টিশন তৈরি করা হয়, কাফকা নোড জুড়ে সমানভাবে নেতাদের বিতরণ করার চেষ্টা করেন এবং সেই প্রথম নেতাদের পছন্দের হিসাবে চিহ্নিত করেন। সময়ের সাথে সাথে, সার্ভার রিবুট, ব্যর্থতা এবং সংযোগ বিচ্ছিন্নতার কারণে, নেতারা অন্য নোডগুলিতে শেষ হতে পারে, যেমন উপরে বর্ণিত চরম ক্ষেত্রে।

এটি ঠিক করতে, কাফকা দুটি বিকল্প অফার করে:

• বিকল্প auto.leader.rebalance.enable=true কন্ট্রোলার নোডকে স্বয়ংক্রিয়ভাবে পছন্দের প্রতিলিপিগুলিতে নেতাদের পুনরায় বরাদ্দ করার অনুমতি দেয় এবং এর ফলে অভিন্ন বিতরণ পুনরুদ্ধার করে।
• প্রশাসক স্ক্রিপ্ট চালাতে পারেন kafka-preferred-replica-election.sh ম্যানুয়াল পুনরায় নিয়োগের জন্য।

ভাত। 6. ভারসাম্য বজায় রাখার পর প্রতিলিপি

এটি ব্যর্থতার একটি সরলীকৃত সংস্করণ ছিল, তবে বাস্তবতা আরও জটিল, যদিও এখানে খুব জটিল কিছু নেই। এটি সমস্ত সিঙ্ক্রোনাইজড রেপ্লিকা (ইন-সিঙ্ক রেপ্লিকাস, আইএসআর) এ নেমে আসে।

সিঙ্ক্রোনাইজড রেপ্লিকাস (ISR)

একটি আইএসআর একটি পার্টিশনের প্রতিলিপিগুলির একটি সেট যা "সিঙ্ক্রোনাইজড" (ইন-সিঙ্ক) হিসাবে বিবেচিত হয়। নেতা আছে, কিন্তু অনুসারী নাও থাকতে পারে। একটি অনুগামী যদি বিরতির মেয়াদ শেষ হওয়ার আগে সমস্ত নেতার বার্তাগুলির সঠিক অনুলিপি তৈরি করে থাকে তবে তাকে সিঙ্ক্রোনাইজ করা বলে মনে করা হয় replica.lag.time.max.ms.

একজন অনুসরণকারীকে ISR সেট থেকে সরানো হয় যদি এটি:

• বিরতির জন্য নির্বাচন করার অনুরোধ করেনি replica.lag.time.max.ms (মৃত সম্ভাব্য)
• বিরতির সময় আপডেট করতে পরিচালিত হয়নি replica.lag.time.max.ms (ধীরে বিবেচিত)

অনুগামীরা বিরতিতে নমুনা অনুরোধ করে replica.fetch.wait.max.ms, যা ডিফল্ট 500ms.

ISR এর উদ্দেশ্য স্পষ্টভাবে ব্যাখ্যা করার জন্য, আমাদের প্রযোজকের কাছ থেকে নিশ্চিতকরণ এবং কিছু ব্যর্থতার পরিস্থিতি দেখতে হবে। ব্রোকার যখন নিশ্চিতকরণ পাঠাবে তখন প্রযোজকরা বেছে নিতে পারেন:

• acks=0, নিশ্চিতকরণ পাঠানো হয় না
• acks=1, নেতা তার স্থানীয় লগে একটি বার্তা লেখার পরে নিশ্চিতকরণ পাঠানো হয়
• acks=all, ISR-এর সমস্ত প্রতিলিপি স্থানীয় লগগুলিতে বার্তা লেখার পরে নিশ্চিতকরণ পাঠানো হয়

কাফকার পরিভাষায়, যদি আইএসআর একটি বার্তা সংরক্ষণ করে থাকে, তবে এটি "প্রতিশ্রুতিবদ্ধ"। Acks=all হল সবচেয়ে নিরাপদ বিকল্প, কিন্তু অতিরিক্ত বিলম্বও যোগ করে। আসুন ব্যর্থতার দুটি উদাহরণ দেখি এবং কীভাবে বিভিন্ন 'অ্যাক্স' বিকল্পগুলি আইএসআর ধারণার সাথে ইন্টারঅ্যাক্ট করে।

Acks=1 এবং ISR

এই উদাহরণে, আমরা দেখতে পাব যে নেতা যদি সমস্ত অনুগামীদের থেকে প্রতিটি বার্তা সংরক্ষণের জন্য অপেক্ষা না করেন, তবে নেতা ব্যর্থ হলে ডেটা ক্ষতি সম্ভব। সিঙ্ক না করা অনুসরণকারীর কাছে নেভিগেট করা সেটিংয়ের মাধ্যমে সক্ষম বা অক্ষম করা যেতে পারে unclean.leader.election.enable.

এই উদাহরণে, প্রস্তুতকারকের মান acks=1 আছে। বিভাগটি তিনটি দালাল জুড়ে বিতরণ করা হয়। ব্রোকার 3 পিছনে রয়েছে, এটি আট সেকেন্ড আগে নেতার সাথে সিঙ্ক্রোনাইজ হয়েছে এবং এখন 7456 বার্তা পিছনে রয়েছে। ব্রোকার 1 মাত্র এক সেকেন্ড পিছিয়ে ছিল। আমাদের প্রযোজক একটি বার্তা পাঠান এবং দ্রুত একটি অ্যাক ফিরে পান, ধীরগতির বা মৃত অনুসারীদের ওভারহেড ছাড়াই যার জন্য নেতা অপেক্ষা করছেন না।

ভাত। 7. তিনটি প্রতিলিপি সহ ISR

ব্রোকার 2 ব্যর্থ হয় এবং প্রযোজক একটি সংযোগ ত্রুটি পায়। নেতৃত্ব ব্রোকার 1-এ চলে যাওয়ার পর, আমরা 123টি বার্তা হারাই। ব্রোকার 1-এর অনুগামীটি আইএসআর-এর অংশ ছিল, কিন্তু যখন এটি পড়ে যায় তখন নেতার সাথে সম্পূর্ণরূপে সিঙ্ক্রোনাইজ করা হয়নি।

ভাত। 8. এটি ক্র্যাশ হলে বার্তা হারিয়ে যায়

কনফিগারেশনে bootstrap.servers প্রস্তুতকারকের তালিকাভুক্ত বেশ কয়েকটি ব্রোকার রয়েছে এবং অন্য ব্রোকারকে জিজ্ঞাসা করতে পারেন যিনি নতুন বিভাগের নেতা। এটি তারপর ব্রোকার 1 এর সাথে একটি সংযোগ স্থাপন করে এবং বার্তা পাঠানো অব্যাহত রাখে।

ভাত। 9. একটি ছোট বিরতির পরে বার্তা পাঠানো আবার শুরু হয়

ব্রোকার 3 আরও পিছিয়ে। এটি আনার অনুরোধ করে কিন্তু সিঙ্ক করতে পারে না। এটি ব্রোকারদের মধ্যে ধীর গতির নেটওয়ার্ক সংযোগ, স্টোরেজ সমস্যা ইত্যাদির কারণে হতে পারে৷ এটি ISR থেকে সরানো হয়েছে৷ এখন আইএসআর একটি প্রতিরূপ নিয়ে গঠিত - নেতা! প্রস্তুতকারক বার্তা পাঠাতে এবং নিশ্চিতকরণ গ্রহণ অব্যাহত.

ভাত। 10. ব্রোকার 3-এর অনুসরণকারীকে ISR থেকে সরিয়ে দেওয়া হয়

ব্রোকার 1 কমে যায় এবং নেতৃত্বের ভূমিকা ব্রোকার 3-এর কাছে যায় 15286টি বার্তা হারিয়ে যায়! নির্মাতা একটি সংযোগ ত্রুটি বার্তা পায়। আইএসআর-এর বাইরে একজন নেতার রূপান্তর শুধুমাত্র সেটিং এর কারণেই সম্ভব হয়েছিল unclean.leader.election.enable=true. যদি এটি ইনস্টল করা হয় মিথ্যা, তাহলে রূপান্তর ঘটবে না এবং সমস্ত পড়া এবং লেখার অনুরোধ প্রত্যাখ্যান করা হবে। এই ক্ষেত্রে, আমরা ব্রোকার 1 এর প্রতিলিপিতে তার অক্ষত ডেটা নিয়ে ফিরে আসার জন্য অপেক্ষা করি, যা আবার নেতৃত্ব গ্রহণ করবে।

ভাত। 11. ব্রোকার 1 পড়ে। যখন একটি ব্যর্থতা ঘটে, তখন প্রচুর সংখ্যক বার্তা হারিয়ে যায়

প্রযোজক শেষ দালালের সাথে একটি সংযোগ স্থাপন করে এবং দেখেন যে তিনি এখন বিভাগের নেতা। সে দালাল 3-কে বার্তা পাঠাতে শুরু করে।

ভাত। 12. একটি ছোট বিরতির পরে, বার্তাগুলি আবার সেকশন 0 এ পাঠানো হয়৷

আমরা দেখেছি যে, নতুন সংযোগ স্থাপন এবং একটি নতুন নেতার সন্ধানের জন্য সংক্ষিপ্ত বাধা ছাড়াও, নির্মাতা ক্রমাগত বার্তা পাঠাচ্ছেন। এই কনফিগারেশনটি সামঞ্জস্যের (ডেটা নিরাপত্তা) খরচে প্রাপ্যতা নিশ্চিত করে। কাফকা হাজার হাজার বার্তা হারিয়েছেন কিন্তু নতুন লেখা গ্রহণ করতে থাকেন।

Acks=সমস্ত এবং ISR

এর আবার এই দৃশ্যকল্প পুনরাবৃত্তি করা যাক, কিন্তু সঙ্গে acks=সমস্ত. ব্রোকার 3-এর গড় বিলম্বিতা চার সেকেন্ড। প্রস্তুতকারকের সাথে একটি বার্তা পাঠায় acks=সমস্ত, এবং এখন একটি দ্রুত প্রতিক্রিয়া পায় না. নেতা আইএসআর-এর সমস্ত প্রতিলিপি দ্বারা বার্তাটি সংরক্ষণ করার জন্য অপেক্ষা করছেন।

ভাত। 13. তিনটি প্রতিলিপি সহ ISR। একটি ধীর, ফলে রেকর্ডিং বিলম্ব হয়

অতিরিক্ত বিলম্বের চার সেকেন্ড পরে, ব্রোকার 2 একটি ack পাঠায়। সব প্রতিলিপি এখন সম্পূর্ণরূপে আপডেট করা হয়.

ভাত। 14. সমস্ত প্রতিলিপি বার্তা সংরক্ষণ এবং ack পাঠান

ব্রোকার 3 এখন আরও পিছিয়ে পড়ে এবং ISR থেকে সরানো হয়েছে। লেটেন্সি উল্লেখযোগ্যভাবে কমে গেছে কারণ আইএসআর-এ কোন ধীর প্রতিলিপি অবশিষ্ট নেই। ব্রোকার 2 এখন শুধুমাত্র ব্রোকার 1-এর জন্য অপেক্ষা করে, এবং তার গড় ব্যবধান 500 ms।

ভাত। 15. ব্রোকার 3-এর প্রতিরূপটি ISR থেকে সরানো হয়েছে

তারপর ব্রোকার 2 পড়ে যায় এবং নেতৃত্ব বার্তার ক্ষতি ছাড়াই ব্রোকার 1-এর কাছে চলে যায়।

ভাত। 16. ব্রোকার 2 পড়ে

নির্মাতা একটি নতুন নেতা খুঁজে পান এবং তাকে বার্তা পাঠাতে শুরু করেন। লেটেন্সি আরও কমেছে কারণ ISR এখন একটি রেপ্লিকা নিয়ে গঠিত! অতএব বিকল্প acks=সমস্ত অপ্রয়োজনীয়তা যোগ করে না।

ভাত। 17. ব্রোকার 1-এর প্রতিলিপি বার্তা না হারিয়েই নেতৃত্ব দেয়

তারপর ব্রোকার 1 ক্র্যাশ হয়ে যায় এবং 3 মেসেজের ক্ষতির সাথে ব্রোকার 14238-এ লিড চলে যায়!

ভাত। 18. ব্রোকার 1 মারা যায় এবং অপরিষ্কার সেটিং সহ নেতৃত্বের পরিবর্তনের ফলে ব্যাপক ডেটা ক্ষতি হয়

আমরা বিকল্পটি ইনস্টল করতে পারিনি unclean.leader.election.enable অর্থে সত্য. ডিফল্টরূপে এটি সমান মিথ্যা. সেটিংস acks=সমস্ত с 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 আপনার প্রয়োজন অনুযায়ী। মূলত, এই পরামিতি মানে কত বিলম্ব আমরা কখন গ্রহণ করতে ইচ্ছুক acks=সমস্ত. ডিফল্ট মান দশ সেকেন্ড। এটি আপনার জন্য খুব দীর্ঘ হলে, আপনি এটি কমাতে পারেন। তারপর ISR-এ পরিবর্তনের ফ্রিকোয়েন্সি বাড়বে, যেহেতু অনুগামীদের সরানো হবে এবং আরও প্রায়ই যোগ করা হবে।

RabbitMQ হল আয়নার একটি সেট যা প্রতিলিপি করা দরকার। ধীর আয়নাগুলি অতিরিক্ত লেটেন্সি প্রবর্তন করে, এবং মৃত আয়নাগুলি অপেক্ষা করতে পারে যতক্ষণ না প্যাকেটগুলি প্রতিটি নোডের (নেট টিক) উপলব্ধতা পরীক্ষা করে প্রতিক্রিয়া জানাতে। এই লেটেন্সি সমস্যাগুলি এড়াতে আইএসআর একটি আকর্ষণীয় উপায়। কিন্তু আমরা অপ্রয়োজনীয়তা হারানোর ঝুঁকি নিয়ে থাকি কারণ ISR শুধুমাত্র নেতার কাছে সঙ্কুচিত হতে পারে। এই ঝুঁকি এড়াতে, সেটিং ব্যবহার করুন min.insync.replicas.

ক্লায়েন্ট সংযোগ গ্যারান্টি

সেটিংসে bootstrap.servers প্রযোজক এবং ভোক্তা ক্লায়েন্ট সংযোগ করার জন্য একাধিক ব্রোকার নির্দিষ্ট করতে পারেন। ধারণাটি হল যে যখন একটি নোড নিচে চলে যায়, তখন বেশ কয়েকটি অতিরিক্ত অবশিষ্ট থাকে যা দিয়ে ক্লায়েন্ট একটি সংযোগ খুলতে পারে। এগুলি অগত্যা বিভাগের নেতা নয়, তবে প্রাথমিক লোডিংয়ের জন্য কেবল একটি স্প্রিংবোর্ড। ক্লায়েন্ট তাদের জিজ্ঞাসা করতে পারে কোন নোডটি রিড/রাইট পার্টিশন লিডার হোস্ট করে।

RabbitMQ-তে, ক্লায়েন্টরা যেকোনো নোডের সাথে সংযোগ করতে পারে এবং অভ্যন্তরীণ রাউটিং অনুরোধটি যেখানে যেতে হবে সেখানে পাঠায়। এর মানে হল যে আপনি RabbitMQ এর সামনে একটি লোড ব্যালেন্সার ইনস্টল করতে পারেন। কাফকা ক্লায়েন্টদের সেই নোডের সাথে সংযোগ করতে চান যা সংশ্লিষ্ট পার্টিশন লিডারকে হোস্ট করে। এই ধরনের পরিস্থিতিতে, আপনি একটি লোড ব্যালেন্সার ইনস্টল করতে পারবেন না। তালিকা bootstrap.servers এটি গুরুত্বপূর্ণ যে ক্লায়েন্টরা একটি ব্যর্থতার পরে সঠিক নোডগুলি অ্যাক্সেস করতে এবং খুঁজে পেতে পারে।

কাফকা কনসেনসাস আর্কিটেকচার

এখন পর্যন্ত, আমরা বিবেচনা করিনি কিভাবে ক্লাস্টার দালালের পতন সম্পর্কে জানতে পারে এবং কীভাবে একজন নতুন নেতা নির্বাচিত হয়। কাফকা কীভাবে নেটওয়ার্ক পার্টিশনের সাথে কাজ করে তা বোঝার জন্য, আপনাকে প্রথমে ঐক্যমত্য আর্কিটেকচার বুঝতে হবে।

প্রতিটি কাফকা ক্লাস্টার একটি জুকিপার ক্লাস্টারের সাথে মোতায়েন করা হয়, যা একটি বিতরণকৃত ঐক্যমত্য পরিষেবা যা সিস্টেমকে প্রাপ্যতার উপর সামঞ্জস্যতাকে অগ্রাধিকার দিয়ে কিছু নির্দিষ্ট রাজ্যে ঐক্যমতে পৌঁছাতে দেয়। পড়া এবং লেখার ক্রিয়াকলাপ অনুমোদনের জন্য বেশিরভাগ Zookeeper নোডের সম্মতি প্রয়োজন।

জুকিপার ক্লাস্টারের অবস্থা সংরক্ষণ করে:

• বিষয়ের তালিকা, বিভাগ, কনফিগারেশন, বর্তমান নেতার প্রতিলিপি, পছন্দের প্রতিলিপি।
• ক্লাস্টার সদস্য। প্রতিটি ব্রোকার জুকিপার ক্লাস্টারে পিং করে। যদি এটি একটি নির্দিষ্ট সময়ের মধ্যে একটি পিং না পায়, তাহলে জুকিপার ব্রোকারকে অনুপলব্ধ হিসাবে রেকর্ড করে।
• নিয়ামকের জন্য প্রধান এবং অতিরিক্ত নোড নির্বাচন করা।

কন্ট্রোলার নোড হল কাফকার দালালদের মধ্যে একটি যা প্রতিরূপ নেতা নির্বাচনের জন্য দায়ী। জুকিপার ক্লাস্টার সদস্যতা এবং বিষয় পরিবর্তন সম্পর্কে নিয়ামককে বিজ্ঞপ্তি পাঠায় এবং নিয়ামককে অবশ্যই এই পরিবর্তনগুলিতে কাজ করতে হবে।

উদাহরণস্বরূপ, দশটি পার্টিশন এবং 3-এর একটি প্রতিলিপি ফ্যাক্টর সহ একটি নতুন বিষয় নেওয়া যাক। কন্ট্রোলারকে অবশ্যই প্রতিটি পার্টিশনের জন্য একজন নেতা নির্বাচন করতে হবে, ব্রোকারদের মধ্যে নেতাদের সর্বোত্তমভাবে বিতরণ করার চেষ্টা করে।

প্রতিটি বিভাগ নিয়ন্ত্রকের জন্য:

• ISR এবং নেতা সম্পর্কে Zookeeper-এ তথ্য আপডেট করে;
• এই পার্টিশনের একটি প্রতিরূপ হোস্ট করে এমন প্রতিটি ব্রোকারকে একটি লিডার এবং আইএসআরকমান্ড পাঠায়, দালালদের আইএসআর এবং নেতা সম্পর্কে অবহিত করে।

যখন একজন নেতার সাথে একজন দালাল পড়ে যায়, তখন জুকিপার নিয়ন্ত্রকের কাছে একটি বিজ্ঞপ্তি পাঠায় এবং এটি একটি নতুন নেতা নির্বাচন করে। আবার, নিয়ন্ত্রক প্রথমে জুকিপারকে আপডেট করে এবং তারপর প্রতিটি ব্রোকারকে নেতৃত্বের পরিবর্তন সম্পর্কে অবহিত করে একটি কমান্ড পাঠায়।

প্রতিটি নেতা আইএসআর নিয়োগের জন্য দায়ী। সেটিংস replica.lag.time.max.ms কে সেখানে প্রবেশ করবে তা নির্ধারণ করে। যখন আইএসআর পরিবর্তন হয়, তখন নেতা চিড়িয়াখানার কাছে নতুন তথ্য প্রেরণ করেন।

চিড়িয়াখানার রক্ষককে সর্বদা যেকোন পরিবর্তন সম্পর্কে অবহিত করা হয় যাতে ব্যর্থতার ক্ষেত্রে, ব্যবস্থাপনা একটি নতুন নেতার কাছে সহজে স্থানান্তরিত হয়।

ভাত। 21. কাফকা কনসেনসাস

প্রতিলিপি প্রোটোকল

প্রতিলিপির বিশদ বিবরণ বোঝা আপনাকে সম্ভাব্য ডেটা ক্ষতির পরিস্থিতি আরও ভালভাবে বুঝতে সাহায্য করে।

নমুনা প্রশ্ন, লগ এন্ড অফসেট (LEO) এবং হাইওয়াটার মার্ক (HW)

আমরা বিবেচনা করেছি যে অনুগামীরা পর্যায়ক্রমে নেতার কাছে আনার অনুরোধ পাঠান। ডিফল্ট ব্যবধান হল 500ms। এটি RabbitMQ থেকে আলাদা যে RabbitMQ-এ প্রতিলিপি সারি আয়না দ্বারা শুরু হয় না কিন্তু মাস্টার দ্বারা। মাস্টার আয়না পরিবর্তন ধাক্কা.

নেতা এবং সমস্ত অনুগামীরা লগ এন্ড অফসেট (LEO) এবং হাইওয়াটার (HW) লেবেল সংরক্ষণ করে। LEO চিহ্ন স্থানীয় প্রতিরূপে শেষ বার্তাটির অফসেট সংরক্ষণ করে এবং HW শেষ কমিটের অফসেট ধরে রাখে। মনে রাখবেন যে কমিট স্ট্যাটাসের জন্য, বার্তাটি অবশ্যই সমস্ত ISR রেপ্লিকা জুড়ে থাকতে হবে। এর মানে হল যে LEO সাধারণত HW এর থেকে কিছুটা এগিয়ে থাকে।

যখন নেতা একটি বার্তা পায়, এটি স্থানীয়ভাবে সংরক্ষণ করে। অনুসরণকারী তার LEO প্রেরণ করে একটি আনার অনুরোধ করে। নেতা তখন এই LEO থেকে শুরু করে এক ব্যাচের বার্তা পাঠান এবং বর্তমান HW-কেও প্রেরণ করেন। যখন নেতা তথ্য পান যে সমস্ত প্রতিলিপিগুলি প্রদত্ত অফসেটে বার্তাটি সংরক্ষণ করেছে, তখন এটি HW চিহ্নকে সরিয়ে দেয়। শুধুমাত্র নেতাই HW কে স্থানান্তর করতে পারেন, এবং তাই সমস্ত অনুগামীরা তাদের অনুরোধের প্রতিক্রিয়াতে বর্তমান মান জানতে পারবে। এর মানে হল যে অনুগামীরা বার্তা এবং HW জ্ঞান উভয় ক্ষেত্রেই নেতার থেকে পিছিয়ে থাকতে পারে। ভোক্তারা শুধুমাত্র বর্তমান HW পর্যন্ত বার্তা গ্রহণ করে।

মনে রাখবেন যে "স্থির" মানে মেমরিতে লেখা, ডিস্কে নয়। পারফরম্যান্সের জন্য, কাফকা একটি নির্দিষ্ট ব্যবধানে ডিস্কে সিঙ্ক্রোনাইজ করে। RabbitMQ-তেও এই ধরনের একটি ব্যবধান রয়েছে, কিন্তু এটি শুধুমাত্র মাস্টার এবং সমস্ত মিরর ডিস্কে বার্তাটি লেখার পরেই প্রকাশকের কাছে একটি স্বীকৃতি পাঠাবে। কাফকা বিকাশকারীরা, কর্মক্ষমতার কারণে, মেমরিতে বার্তা লেখার সাথে সাথে একটি ack পাঠানোর সিদ্ধান্ত নিয়েছে। কাফকা বাজি ধরেন যে অপ্রয়োজনীয়তা শুধুমাত্র মেমরিতে স্বীকৃত বার্তাগুলি সংক্ষিপ্তভাবে সংরক্ষণ করার ঝুঁকি অফসেট করে।

নেতার ব্যর্থতা

যখন একজন নেতা পড়ে যায়, তখন জুকিপার নিয়ামককে অবহিত করে এবং এটি একটি নতুন নেতার প্রতিরূপ নির্বাচন করে। নতুন নেতা তার LEO অনুযায়ী একটি নতুন HW চিহ্ন সেট করে। অনুগামীরা তারপর নতুন নেতা সম্পর্কে তথ্য পায়। কাফকার সংস্করণের উপর নির্ভর করে, অনুসরণকারী দুটি পরিস্থিতির মধ্যে একটি বেছে নেবে:

1. এটি একটি পরিচিত HW-তে স্থানীয় লগ ছেঁটে ফেলবে এবং এই চিহ্নের পরে বার্তাগুলির জন্য নতুন নেতার কাছে একটি অনুরোধ পাঠাবে।
2. তিনি নেতা নির্বাচিত হওয়ার সময় HW খুঁজে বের করার জন্য নেতার কাছে একটি অনুরোধ পাঠাবেন, এবং তারপর এই অফসেটে লগটি ছেঁটে ফেলবেন। এটি তারপর এই অফসেট থেকে শুরু করে পর্যায়ক্রমিক আনার অনুরোধ করা শুরু করবে।

একজন অনুসরণকারীকে নিম্নলিখিত কারণে লগটি কাটার প্রয়োজন হতে পারে:

• যখন একজন নেতা ব্যর্থ হন, তখন জুকিপারের সাথে নিবন্ধিত ISR সেটের প্রথম অনুসারী নির্বাচনে জয়ী হন এবং নেতা হন। ISR-এর সমস্ত অনুগামীরা, যদিও "সিঙ্কে" হিসাবে বিবেচিত হয়, তারা প্রাক্তন নেতার সমস্ত বার্তার অনুলিপি নাও পেতে পারে৷ এটি সম্পূর্ণরূপে সম্ভব যে বৈশিষ্ট্যযুক্ত অনুসরণকারীর কাছে সর্বাধিক আপ-টু-ডেট অনুলিপি নেই। কাফকা নিশ্চিত করেন যে প্রতিলিপিগুলির মধ্যে কোন ভিন্নতা নেই। এইভাবে, অসঙ্গতি এড়াতে, প্রতিটি অনুসারীকে তার নির্বাচনের সময় নতুন নেতার HW মান অনুসারে তার লগকে ছেঁটে ফেলতে হবে। এটি সেটিং কেন অন্য কারণ acks=সমস্ত ধারাবাহিকতার জন্য তাই গুরুত্বপূর্ণ।
• বার্তাগুলি পর্যায়ক্রমে ডিস্কে লেখা হয়। যদি সমস্ত ক্লাস্টার নোড একই সময়ে ব্যর্থ হয়, তাহলে বিভিন্ন অফসেট সহ প্রতিলিপিগুলি ডিস্কগুলিতে সংরক্ষণ করা হবে। এটা সম্ভব যে যখন দালালরা অনলাইনে ফিরে আসবে, তখন যে নতুন নেতা নির্বাচিত হবেন তিনি তার অনুসারীদের পিছনে থাকবেন কারণ তিনি অন্যদের আগে ডিস্কে সংরক্ষণ করেছিলেন।

ক্লাস্টারের সাথে পুনর্মিলন

ক্লাস্টারে পুনরায় যোগদান করার সময়, প্রতিলিপিগুলি একই কাজ করে যখন একজন নেতা ব্যর্থ হয়: তারা নেতার প্রতিরূপ পরীক্ষা করে এবং তাদের লগ তার HW (নির্বাচনের সময়) ছেঁটে দেয়। তুলনায়, RabbitMQ সমানভাবে পুনর্মিলিত নোডকে সম্পূর্ণ নতুন হিসাবে বিবেচনা করে। উভয় ক্ষেত্রেই, ব্রোকার বিদ্যমান যেকোনো রাষ্ট্রকে বাতিল করে দেয়। যদি স্বয়ংক্রিয় সিঙ্ক্রোনাইজেশন ব্যবহার করা হয়, তবে মাস্টারকে অবশ্যই "পুরো বিশ্বকে অপেক্ষা করতে দিন" পদ্ধতিতে নতুন আয়নায় একেবারে সমস্ত বর্তমান সামগ্রী প্রতিলিপি করতে হবে। এই অপারেশন চলাকালীন মাস্টার কোন পড়া বা লেখার অপারেশন গ্রহণ করেন না। এই পদ্ধতিটি বড় সারিতে সমস্যা তৈরি করে।

কাফকা একটি বিতরণ করা লগ এবং সাধারণভাবে এটি একটি RabbitMQ সারির চেয়ে বেশি বার্তা সঞ্চয় করে, যেখানে ডেটা পড়ার পরে সারির থেকে সরানো হয়। সক্রিয় সারি অপেক্ষাকৃত ছোট থাকা উচিত. কিন্তু কাফকা তার নিজস্ব ধারণ নীতি সহ একটি লগ, যা দিন বা সপ্তাহের একটি সময় নির্ধারণ করতে পারে। কিউ ব্লকিং এবং সম্পূর্ণ সিঙ্ক্রোনাইজেশন পদ্ধতি একটি বিতরণ করা লগের জন্য একেবারে অগ্রহণযোগ্য। পরিবর্তে, কাফকার অনুসারীরা নেতার এইচডব্লিউতে (তার নির্বাচনের সময়) তাদের লগ ছেঁটে দেয় যদি তাদের অনুলিপি নেতার চেয়ে এগিয়ে থাকে। আরও সম্ভাব্য ক্ষেত্রে, যখন অনুসরণকারী পিছনে থাকে, তখন এটি কেবল তার বর্তমান LEO থেকে শুরু করে আনার অনুরোধ করা শুরু করে।

নতুন বা পুনরায় যোগদানকারী অনুগামীরা ISR এর বাইরে শুরু করে এবং কমিটগুলিতে অংশগ্রহণ করে না। তারা কেবল গ্রুপের সাথে কাজ করে, যত তাড়াতাড়ি সম্ভব বার্তা গ্রহণ করে যতক্ষণ না তারা নেতার সাথে যোগাযোগ করে এবং ISR তে প্রবেশ করে। কোনও লক-ইন নেই এবং আপনার সমস্ত ডেটা ফেলে দেওয়ার দরকার নেই।

সংযোগ বিঘ্নিত

কাফকাতে RabbitMQ এর চেয়ে বেশি উপাদান রয়েছে, তাই ক্লাস্টারটি সংযোগ বিচ্ছিন্ন হয়ে গেলে এটিতে আরও জটিল আচরণ রয়েছে। কিন্তু কাফকা মূলত ক্লাস্টারগুলির জন্য ডিজাইন করা হয়েছিল, তাই সমাধানগুলি খুব ভালভাবে চিন্তা করা হয়েছে।

নীচে কয়েকটি সংযোগ ব্যর্থতার পরিস্থিতি রয়েছে:

• দৃশ্য 1: অনুসরণকারী নেতাকে দেখতে পায় না, কিন্তু তবুও চিড়িয়াখানাকে দেখে।
• দৃশ্যকল্প 2: নেতা কোনো অনুগামীদের দেখতে পান না, কিন্তু তবুও চিড়িয়াখানাকে দেখেন।
• দৃশ্য 3: অনুগামী নেতাকে দেখে, কিন্তু চিড়িয়াখানাকে দেখে না।
• দৃশ্যকল্প 4: নেতা অনুগামীদের দেখেন, কিন্তু চিড়িয়াখানাকে দেখেন না।
• দৃশ্যকল্প 5: অনুগামী অন্য কাফকা নোড এবং জুকিপার উভয় থেকে সম্পূর্ণ আলাদা।
• দৃশ্যকল্প 6: নেতা অন্য কাফকা নোড এবং জুকিপার উভয় থেকে সম্পূর্ণ আলাদা।
• দৃশ্য 7: কাফকা কন্ট্রোলার নোড অন্য কাফকা নোড দেখতে পারে না।
• দৃশ্য 8: কাফকা নিয়ন্ত্রক চিড়িয়াখানাকে দেখতে পান না।

প্রতিটি দৃশ্যের নিজস্ব আচরণ আছে।

দৃশ্যকল্প 1: অনুসরণকারী নেতাকে দেখতে পায় না, কিন্তু তবুও চিড়িয়াখানাকে দেখে

ভাত। 22. দৃশ্যকল্প 1: তিনটি প্রতিলিপির ISR

সংযোগ ব্যর্থতা ব্রোকার 3 কে ব্রোকার 1 এবং 2 থেকে আলাদা করে, কিন্তু Zookeeper থেকে নয়। ব্রোকার 3 আর আনার অনুরোধ পাঠাতে পারবে না। সময় পার হওয়ার পর replica.lag.time.max.ms এটি আইএসআর থেকে সরানো হয় এবং বার্তা প্রতিশ্রুতিতে অংশগ্রহণ করে না। একবার কানেক্টিভিটি পুনরুদ্ধার করা হলে, এটি পুনরায় অনুরোধ আনা শুরু করবে এবং নেতার সাথে যোগাযোগ করলে ISR-এ যোগদান করবে। চিড়িয়াখানার কর্মী পিং পেতে থাকবে এবং অনুমান করবে যে দালাল জীবিত এবং ভাল।

ভাত। 23. দৃশ্যকল্প 1: যদি replica.lag.time.max.ms ব্যবধানে ব্রোকারের কাছ থেকে কোনো আনার অনুরোধ না পাওয়া যায় তাহলে তাকে ISR থেকে সরিয়ে দেওয়া হবে।

RabbitMQ এর মত কোন বিভক্ত-মস্তিষ্ক বা নোড সাসপেনশন নেই। পরিবর্তে, অপ্রয়োজনীয়তা হ্রাস করা হয়।

দৃশ্যকল্প 2: নেতা কোনো অনুগামীদের দেখতে পান না, কিন্তু তবুও চিড়িয়াখানাকে দেখেন

ভাত। 24. দৃশ্যকল্প 2. নেতা এবং দুই অনুসারী

নেটওয়ার্ক সংযোগে একটি ভাঙ্গন নেতাকে অনুগামীদের থেকে আলাদা করে, কিন্তু দালাল এখনও জুকিপারকে দেখতে পারে। প্রথম দৃশ্যের মতো, ISR সঙ্কুচিত হয়, কিন্তু এইবার শুধুমাত্র নেতার কাছে কারণ সমস্ত অনুগামীরা আনার অনুরোধ পাঠানো বন্ধ করে দেয়। আবার, কোন যৌক্তিক বিভাজন নেই। পরিবর্তে, সংযোগ পুনরুদ্ধার না হওয়া পর্যন্ত নতুন বার্তাগুলির জন্য অপ্রয়োজনীয়তার ক্ষতি রয়েছে৷ চিড়িয়াখানা ক্রমাগত পিং পেতে থাকে এবং বিশ্বাস করে যে দালাল জীবিত এবং ভালো আছে।

ভাত। 25. দৃশ্যকল্প 2. ISR শুধুমাত্র নেতার কাছে সঙ্কুচিত হয়েছে

দৃশ্যকল্প 3. অনুসরণকারী নেতাকে দেখে, কিন্তু চিড়িয়াখানাকে দেখে না

অনুগামী চিড়িয়াখানার থেকে আলাদা হয়, কিন্তু নেতার সাথে দালাল থেকে নয়। ফলস্বরূপ, অনুসরণকারী অনুরোধ আনতে এবং ISR এর সদস্য হতে থাকে। চিড়িয়াখানা আর পিং পায় না এবং একটি ব্রোকার ক্র্যাশ নিবন্ধন করে, কিন্তু যেহেতু এটি শুধুমাত্র একজন অনুসারী, তাই পুনরুদ্ধারের পরে কোন পরিণতি নেই।

ভাত। 26. দৃশ্যকল্প 3: অনুসরণকারী নেতার কাছে আনার অনুরোধ পাঠাতে থাকে

দৃশ্যকল্প 4. নেতা অনুগামীদের দেখেন, কিন্তু চিড়িয়াখানাকে দেখেন না

ভাত। 27. দৃশ্যকল্প 4. নেতা এবং দুই অনুসারী

নেতা চিড়িয়াখানার থেকে বিচ্ছিন্ন, কিন্তু অনুগামীদের সাথে দালালদের থেকে নয়।

ভাত। 28. দৃশ্যকল্প 4: নেতা চিড়িয়াখানার থেকে বিচ্ছিন্ন

কিছু সময়ের পরে, জুকিপার একটি ব্রোকার ব্যর্থতা নিবন্ধন করবে এবং এটি সম্পর্কে নিয়ামককে অবহিত করবে। তিনি তার অনুসারীদের মধ্যে নতুন নেতা নির্বাচন করবেন। যাইহোক, মূল নেতাকে নেতা বলে মনে করে তার কাছ থেকে এন্ট্রি গ্রহণ করতে থাকবে acks=1. অনুগামীরা আর তাকে অনুরোধ আনয়ন পাঠাচ্ছে না, তাই সে তাদের মৃত বলে মনে করবে এবং ISR কে নিজের কাছে সঙ্কুচিত করার চেষ্টা করবে৷ কিন্তু যেহেতু এটির Zookeeper এর সাথে কোন সংযোগ নেই, তাই এটি করতে পারবে না, এবং সেই সময়ে আর কোন এন্ট্রি গ্রহণ করতে অস্বীকার করবে।

বার্তা acks=সমস্ত একটি স্বীকৃতি পাবে না কারণ ISR প্রথমে সমস্ত প্রতিলিপি চালু করে, এবং বার্তাগুলি তাদের কাছে পৌঁছায় না। যখন আসল নেতা তাদের আইএসআর থেকে সরানোর চেষ্টা করে, তখন এটি তা করতে অক্ষম হবে এবং কোনও বার্তা গ্রহণ করা বন্ধ করবে।

ক্লায়েন্টরা শীঘ্রই লিডারের পরিবর্তন লক্ষ্য করে এবং নতুন সার্ভারে রেকর্ড পাঠাতে শুরু করে। একবার নেটওয়ার্ক পুনরুদ্ধার করা হলে, আসল নেতা দেখেন যে এটি আর নেতা নয় এবং লগ ডাইভারজেন্স এড়াতে ব্যর্থতার সময় নতুন নেতার যে HW মান ছিল তার লগকে ছোট করে। তারপরে এটি নতুন নেতার কাছে আনার অনুরোধ পাঠাতে শুরু করবে। মূল নেতার সমস্ত রেকর্ড যা নতুন নেতার সাথে প্রতিলিপি করা হয়নি। অর্থাৎ, দুই নেতা যখন কাজ করছিলেন সেই কয়েক সেকেন্ডের মধ্যে মূল নেতার দ্বারা স্বীকার করা হয়নি এমন বার্তাগুলি হারিয়ে যাবে।

ভাত। 29. দৃশ্যকল্প 4. নেটওয়ার্ক পুনরুদ্ধার করার পরে ব্রোকার 1-এর নেতা একজন অনুসরণকারী হয়ে ওঠেন

দৃশ্যকল্প 5: অনুগামী অন্য কাফকা নোড এবং জুকিপার উভয় থেকে সম্পূর্ণ আলাদা

অনুগামী অন্য কাফকা নোড এবং জুকিপার উভয় থেকে সম্পূর্ণ বিচ্ছিন্ন। নেটওয়ার্ক পুনরুদ্ধার না হওয়া পর্যন্ত তিনি কেবল নিজেকে ISR থেকে সরিয়ে দেন এবং তারপরে অন্যদের সাথে যোগাযোগ করেন।

ভাত। 30. দৃশ্যকল্প 5: ISR থেকে বিচ্ছিন্ন অনুগামী সরানো হয়েছে৷

দৃশ্যকল্প 6: নেতা অন্য কাফকা নোড এবং জুকিপার উভয় থেকে সম্পূর্ণ আলাদা

ভাত। 31. দৃশ্যকল্প 6. নেতা এবং দুই অনুসারী

নেতা তার অনুসারী, নিয়ন্ত্রক এবং চিড়িয়াখানার থেকে সম্পূর্ণ বিচ্ছিন্ন। অল্প সময়ের জন্য এটি থেকে এন্ট্রি গ্রহণ করা অব্যাহত থাকবে acks=1.

ভাত। 32. দৃশ্যকল্প 6: অন্যান্য কাফকা এবং জুকিপার নোড থেকে নেতাকে বিচ্ছিন্ন করা

মেয়াদ শেষ হওয়ার পরে অনুরোধ পাওয়া যায়নি replica.lag.time.max.ms, এটি নিজের কাছে ISR সঙ্কুচিত করার চেষ্টা করবে, কিন্তু Zookeeper এর সাথে কোন যোগাযোগ না থাকায় তা করতে সক্ষম হবে না, তারপর এটি লেখাগুলি গ্রহণ করা বন্ধ করবে৷

ইতিমধ্যে, জুকিপার বিচ্ছিন্ন দালালকে মৃত হিসাবে চিহ্নিত করবে এবং নিয়ন্ত্রক একটি নতুন নেতা নির্বাচন করবে।

ভাত। 33. দৃশ্যকল্প 6. দুই নেতা

মূল নেতা কয়েক সেকেন্ডের জন্য এন্ট্রি গ্রহণ করতে পারে, কিন্তু তারপর কোনো বার্তা গ্রহণ করা বন্ধ করে দেয়। ক্লায়েন্টদের সর্বশেষ মেটাডেটা সহ প্রতি 60 সেকেন্ডে আপডেট করা হয়। তাদের নেতা পরিবর্তন সম্পর্কে অবহিত করা হবে এবং নতুন নেতার কাছে এন্ট্রি পাঠানো শুরু করবে।

ভাত। 34. দৃশ্যকল্প 6: নির্মাতারা একটি নতুন নেতার কাছে যান৷

সংযোগ বিচ্ছিন্ন হওয়ার পর থেকে মূল নেতার করা সমস্ত নিশ্চিত এন্ট্রি হারিয়ে যাবে। একবার নেটওয়ার্ক পুনরুদ্ধার করা হলে, আসল নেতা Zookeeper এর মাধ্যমে আবিষ্কার করবে যে এটি আর নেতা নয়। তারপরে এটি নির্বাচনের সময় নতুন নেতার HW-তে তার লগ ছেঁটে ফেলবে এবং অনুগামী হিসাবে অনুরোধ পাঠাতে শুরু করবে।

ভাত। 35. দৃশ্যকল্প 6: নেটওয়ার্ক সংযোগ পুনরুদ্ধার করার পরে মূল নেতা একজন অনুসারী হয়ে ওঠেন

এই পরিস্থিতিতে, যৌক্তিক বিচ্ছেদ অল্প সময়ের জন্য ঘটতে পারে, কিন্তু শুধুমাত্র যদি acks=1 и min.insync.replicas এছাড়াও 1. যৌক্তিক বিচ্ছেদ স্বয়ংক্রিয়ভাবে শেষ হয় নেটওয়ার্ক পুনরুদ্ধার করার পরে, যখন আসল নেতা বুঝতে পারেন যে তিনি আর নেতা নন, বা যখন সমস্ত ক্লায়েন্ট বুঝতে পারে যে নেতা পরিবর্তিত হয়েছে এবং নতুন নেতাকে লিখতে শুরু করে - যেটি প্রথমে ঘটুক। যে কোনো ক্ষেত্রে, কিছু বার্তা হারিয়ে যাবে, কিন্তু শুধুমাত্র সঙ্গে acks=1.

এই দৃশ্যের আরেকটি রূপ আছে যেখানে, নেটওয়ার্ক বিভক্ত হওয়ার ঠিক আগে, অনুসারীরা পিছনে পড়ে গিয়েছিল এবং নেতা আইএসআরকে কেবল নিজের সাথে সংকুচিত করেছিলেন। সংযোগ বিচ্ছিন্ন হওয়ার কারণে এটি তখন বিচ্ছিন্ন হয়ে পড়ে। একটি নতুন নেতা নির্বাচিত হয়, কিন্তু মূল নেতা এন্ট্রি গ্রহণ অব্যাহত, এমনকি acks=সমস্ত, কারণ তিনি ছাড়া আইএসআরে আর কেউ নেই। নেটওয়ার্ক পুনরুদ্ধার করা হলে এই রেকর্ডগুলি হারিয়ে যাবে৷ এই বিকল্পটি এড়ানোর একমাত্র উপায় min.insync.replicas = 2.

দৃশ্য 7: কাফকা কন্ট্রোলার নোড আরেকটি কাফকা নোড দেখতে পাচ্ছে না

সাধারণভাবে, একবার কাফকা নোডের সাথে সংযোগ বিচ্ছিন্ন হয়ে গেলে, নিয়ন্ত্রক এটিতে কোনও নেতা পরিবর্তনের তথ্য প্রেরণ করতে সক্ষম হবে না। সবচেয়ে খারাপ ক্ষেত্রে, এটি একটি স্বল্প-মেয়াদী যৌক্তিক বিচ্ছেদের দিকে নিয়ে যাবে, যেমনটি 6-এর দৃশ্যকল্পে। প্রায়ই নয়, ব্রোকারটি ব্যর্থ হলে নেতৃত্বের প্রার্থী হবে না।

দৃশ্য 8: কাফকা নিয়ন্ত্রক চিড়িয়াখানাকে দেখতে পান না

চিড়িয়াখানার পতিত নিয়ামক থেকে একটি পিং পাবেন না এবং নিয়ামক হিসাবে একটি নতুন কাফকা নোড নির্বাচন করবে৷ আসল নিয়ামক নিজেকে এইভাবে উপস্থাপন করা চালিয়ে যেতে পারে, কিন্তু এটি Zookeeper থেকে বিজ্ঞপ্তি পায় না, তাই এটি সম্পাদন করার জন্য কোন কাজ থাকবে না। একবার নেটওয়ার্ক পুনরুদ্ধার করা হলে, তিনি বুঝতে পারবেন যে তিনি আর একজন নিয়ন্ত্রক নন, তবে একটি নিয়মিত কাফকা নোডে পরিণত হয়েছেন।

পরিস্থিতি থেকে উপসংহার

আমরা দেখতে পাচ্ছি যে ফলোয়ার কানেক্টিভিটি হারানোর ফলে বার্তা নষ্ট হয় না, কিন্তু নেটওয়ার্ক পুনরুদ্ধার না হওয়া পর্যন্ত অস্থায়ীভাবে রিডানড্যান্সি কমে যায়। এক বা একাধিক নোড হারিয়ে গেলে এটি অবশ্যই ডেটা ক্ষতির কারণ হতে পারে।

সংযোগ বিচ্ছিন্ন হওয়ার কারণে নেতা চিড়িয়াখানার থেকে আলাদা হয়ে গেলে, এর ফলে বার্তাগুলি হারিয়ে যেতে পারে acks=1. চিড়িয়াখানার সাথে যোগাযোগের অভাব দুই নেতার সাথে একটি সংক্ষিপ্ত যৌক্তিক বিচ্ছেদ ঘটায়। এই সমস্যাটি পরামিতি দ্বারা সমাধান করা হয় acks=সমস্ত.

স্থিতিমাপ min.insync.replicas দুই বা ততোধিক প্রতিলিপিগুলি অতিরিক্ত আশ্বাস প্রদান করে যে এই ধরনের স্বল্প-মেয়াদী পরিস্থিতি দৃশ্যকল্প 6-এর মতো হারিয়ে যাওয়া বার্তাগুলির ফলস্বরূপ হবে না।

হারিয়ে যাওয়া বার্তাগুলির সারাংশ

কাফকাতে আপনি যে সমস্ত উপায়ে ডেটা হারাতে পারেন তার তালিকা করা যাক:

• কোনো নেতা ব্যর্থতা যদি বার্তা ব্যবহার করে নিশ্চিত করা হয়েছে acks=1
• নেতৃত্বের কোনো অশুচি রূপান্তর, যে, ISR-এর বাইরের কোনো অনুসারীর কাছে, এমনকি সঙ্গে acks=সমস্ত
• বার্তাগুলি ব্যবহার করে নিশ্চিত হলে চিড়িয়াখানা থেকে নেতাকে বিচ্ছিন্ন করা acks=1
• নেতার সম্পূর্ণ বিচ্ছিন্নতা যিনি ইতিমধ্যেই আইএসআর গ্রুপকে নিজের কাছে সঙ্কুচিত করেছেন। সমস্ত বার্তা হারিয়ে যাবে, এমনকি acks=সমস্ত. এই শুধুমাত্র যদি সত্য min.insync.replicas=1.
• সমস্ত পার্টিশন নোডের একযোগে ব্যর্থতা। কারণ মেমরি থেকে বার্তাগুলি স্বীকার করা হয়, কিছু এখনও ডিস্কে লেখা নাও হতে পারে। সার্ভার রিবুট করার পরে, কিছু বার্তা অনুপস্থিত হতে পারে।

অশুদ্ধ নেতৃত্বের রূপান্তর হয় তাদের নিষিদ্ধ করে বা কমপক্ষে দুটি অপ্রয়োজনীয়তা নিশ্চিত করে এড়ানো যেতে পারে। সবচেয়ে টেকসই কনফিগারেশন একটি সমন্বয় acks=সমস্ত и min.insync.replicas 1 এর বেশি

RabbitMQ এবং Kafka এর নির্ভরযোগ্যতার সরাসরি তুলনা

নির্ভরযোগ্যতা এবং উচ্চ প্রাপ্যতা নিশ্চিত করার জন্য, উভয় প্ল্যাটফর্ম একটি প্রাথমিক এবং মাধ্যমিক প্রতিলিপি সিস্টেম বাস্তবায়ন করে। যাইহোক, RabbitMQ এর একটি অ্যাকিলিস হিল আছে। একটি ব্যর্থতার পরে পুনরায় সংযোগ করার সময়, নোডগুলি তাদের ডেটা বাতিল করে এবং সিঙ্ক্রোনাইজেশন ব্লক করা হয়। এই ডাবল হ্যামিটি RabbitMQ-তে বড় সারিগুলির দীর্ঘায়ু নিয়ে প্রশ্ন তোলে৷ আপনাকে হয় হ্রাসকৃত অপ্রয়োজনীয়তা বা দীর্ঘ ব্লক করার সময় গ্রহণ করতে হবে। অপ্রয়োজনীয়তা হ্রাস ব্যাপক ডেটা ক্ষতির ঝুঁকি বাড়ায়। কিন্তু যদি সারিগুলি ছোট হয়, তাহলে অপ্রয়োজনীয়তার জন্য, বারবার সংযোগের প্রচেষ্টা ব্যবহার করে অল্প সময়ের অনুপলব্ধতা (কয়েক সেকেন্ড) মোকাবেলা করা যেতে পারে।

কাফকার এই সমস্যা নেই। এটি শুধুমাত্র নেতা এবং অনুগামীদের মধ্যে বিচ্ছিন্নতার বিন্দু থেকে ডেটা বাতিল করে। সমস্ত ভাগ করা ডেটা সংরক্ষিত হয়। উপরন্তু, প্রতিলিপি সিস্টেম ব্লক না. নতুন অনুগামীরা ধরা পড়ার সময় নেতা পোস্টগুলি গ্রহণ করতে থাকেন, তাই ডেভপদের জন্য, ক্লাস্টারে যোগদান বা পুনরায় যোগদান করা একটি তুচ্ছ কাজ হয়ে যায়। অবশ্যই, প্রতিলিপি করার সময় নেটওয়ার্ক ব্যান্ডউইথের মতো সমস্যা এখনও রয়েছে। আপনি যদি একই সময়ে একাধিক অনুসরণকারী যোগ করেন, তাহলে আপনি একটি ব্যান্ডউইথ সীমার সম্মুখীন হতে পারেন।

RabbitMQ নির্ভরযোগ্যতার ক্ষেত্রে কাফকার চেয়ে উচ্চতর যখন একটি ক্লাস্টারে একাধিক সার্ভার একই সময়ে ব্যর্থ হয়। আমরা আগেই বলেছি, মাস্টার এবং সমস্ত মিরর দ্বারা ডিস্কে বার্তা লেখার পরেই RabbitMQ প্রকাশককে একটি নিশ্চিতকরণ পাঠায়। কিন্তু এটি দুটি কারণে অতিরিক্ত বিলম্ব যোগ করে:

• fsync প্রতি কয়েকশ মিলিসেকেন্ডে
• প্রতিটি নোড (নেট টিক) এর প্রাপ্যতা পরীক্ষা করে এমন প্যাকেটগুলির জীবনকালের পরেই আয়নার ব্যর্থতা লক্ষ্য করা যায়। যদি আয়নাটি ধীর হয়ে যায় বা পড়ে যায় তবে এটি একটি বিলম্ব যোগ করে।

কাফকার বাজি হল যে যদি একটি বার্তা একাধিক নোড জুড়ে সংরক্ষণ করা হয় তবে এটি মেমরিতে আঘাত করার সাথে সাথে বার্তাগুলিকে স্বীকার করতে পারে। এই কারণে, যে কোনও ধরণের বার্তা হারানোর ঝুঁকি রয়েছে (এমনকি acks=সমস্ত, min.insync.replicas=2) একযোগে ব্যর্থতার ক্ষেত্রে।

সামগ্রিকভাবে, কাফকা আরও ভাল সফ্টওয়্যার কর্মক্ষমতা প্রদর্শন করে এবং ক্লাস্টারগুলির জন্য গ্রাউন্ড আপ থেকে ডিজাইন করা হয়েছে। নির্ভরযোগ্যতার জন্য প্রয়োজনে অনুসারীর সংখ্যা 11-এ বাড়ানো যেতে পারে। রেপ্লিকেশন ফ্যাক্টর 5 এবং সিঙ্ক্রোনাইজেশনে ন্যূনতম সংখ্যক প্রতিলিপি min.insync.replicas=3 বার্তা হারানো একটি খুব বিরল ঘটনা হবে. যদি আপনার পরিকাঠামো এই প্রতিলিপি অনুপাত এবং অপ্রয়োজনীয়তার মাত্রা সমর্থন করতে পারে, তাহলে আপনি এই বিকল্পটি বেছে নিতে পারেন।

RabbitMQ ক্লাস্টারিং ছোট সারিগুলির জন্য ভাল। তবে ভারী যানবাহন থাকলে ছোট সারিগুলিও দ্রুত বাড়তে পারে। একবার সারিগুলি বড় হয়ে গেলে, আপনাকে প্রাপ্যতা এবং নির্ভরযোগ্যতার মধ্যে কঠিন পছন্দ করতে হবে। RabbitMQ ক্লাস্টারিং অ-সাধারণ পরিস্থিতিগুলির জন্য সবচেয়ে উপযুক্ত যেখানে RabbitMQ এর নমনীয়তার সুবিধাগুলি এর ক্লাস্টারিংয়ের যে কোনও অসুবিধার চেয়ে বেশি।

বড় সারিগুলির প্রতি RabbitMQ এর দুর্বলতার একটি প্রতিষেধক হল সেগুলিকে অনেকগুলি ছোট সারিতে বিভক্ত করা। আপনার যদি সম্পূর্ণ সারির সম্পূর্ণ অর্ডারের প্রয়োজন না হয়, তবে শুধুমাত্র প্রাসঙ্গিক বার্তাগুলি (উদাহরণস্বরূপ, একটি নির্দিষ্ট ক্লায়েন্টের বার্তা), বা একেবারেই অর্ডার না করে, তাহলে এই বিকল্পটি গ্রহণযোগ্য: আমার প্রকল্পটি দেখুন রিব্যালান্সার সারি বিভক্ত করতে (প্রকল্পটি এখনও প্রাথমিক পর্যায়ে রয়েছে)।

অবশেষে, RabbitMQ এবং Kafka উভয়ের ক্লাস্টারিং এবং রেপ্লিকেশন মেকানিজমের বেশ কয়েকটি বাগ সম্পর্কে ভুলবেন না। সময়ের সাথে সাথে, সিস্টেমগুলি আরও পরিপক্ক এবং স্থিতিশীল হয়ে উঠেছে, কিন্তু কোনও বার্তাই ক্ষতি থেকে 100% নিরাপদ হবে না! এ ছাড়া ডাটা সেন্টারে বড় ধরনের দুর্ঘটনা ঘটছে!

যদি আমি কিছু মিস করি, ভুল করে থাকি, বা আপনি যেকোন পয়েন্টের সাথে একমত না হন তবে নির্দ্বিধায় একটি মন্তব্য লিখুন বা আমার সাথে যোগাযোগ করুন।

আমাকে প্রায়ই জিজ্ঞাসা করা হয়: "কি বেছে নেবেন, কাফকা বা র‌্যাবিটএমকিউ?", "কোন প্ল্যাটফর্মটি ভাল?"। সত্য হল যে এটি সত্যিই আপনার পরিস্থিতি, বর্তমান অভিজ্ঞতা ইত্যাদির উপর নির্ভর করে৷ আমি আমার মতামত দিতে দ্বিধা বোধ করছি কারণ সমস্ত ব্যবহারের ক্ষেত্রে এবং সম্ভাব্য সীমাবদ্ধতার জন্য একটি প্ল্যাটফর্মের সুপারিশ করা খুব বেশি সরলীকরণ হবে৷ আমি নিবন্ধগুলির এই সিরিজটি লিখেছি যাতে আপনি নিজের মতামত তৈরি করতে পারেন।

আমি বলতে চাই যে উভয় সিস্টেমই এই এলাকার নেতা। আমি কিছুটা পক্ষপাতদুষ্ট হতে পারি কারণ প্রকল্পগুলির সাথে আমার অভিজ্ঞতা থেকে আমি নিশ্চিত বার্তা অর্ডার এবং নির্ভরযোগ্যতার মতো জিনিসগুলিকে মূল্য দিতে চাই।

আমি অন্যান্য প্রযুক্তি দেখতে পাই যেগুলির মধ্যে এই নির্ভরযোগ্যতা এবং নিশ্চিত অর্ডারের অভাব রয়েছে, তারপর আমি RabbitMQ এবং Kafka-এর দিকে তাকাই এবং এই দুটি সিস্টেমের অবিশ্বাস্য মূল্য উপলব্ধি করি৷

উত্স: www.habr.com