مؤلف | Cxuan

المسؤول | إيلي

إذا كنت تستخدم فقط Kafka لتطوير تطبيقات Kafka أو استخدام Kafka في بيئة الإنتاج ، فإن فهم مبدأ العمل الداخلي في Kafka ليس ضروريًا. ومع ذلك ، فإن فهم مبدأ العمل الداخلي لكافكا يساعد على فهم سلوك كافكا ، ويستخدم أيضًا مشكلة التشخيص السريع. دعونا نناقش هذه القضايا الثلاث

• كيف نسخ كافكا

• كيف تتعامل كافكا مع طلبات المنتجين والمستهلكين

• ما هي تفاصيل تخزين كافكا؟

إذا كنت مهتمًا ، فيرجى قضاء بعض الوقت وقراءة هذه المقالة بصبر.

العلاقة بين أعضاء الكتلة

نحن نعلم أن كافكا يركض فوق Zookeeper ، لأن Zookeeper يظهر في مجموعة ، لذلك يمكن أن تظهر Kafka أيضًا في المجموعة. يتضمن ذلك أيضًا مسألة عدد المنتجين والمستهلكين المتعددين. تتم أيضًا العلاقة بين الصيانة بين مجموعة الصيانة بواسطة Zookeeper. إذا قرأت مقالتي السابقة (حقًا ، يكفي قراءة هذا المقال عن كافكا) ، فيجب أن تعلم أنه سيكون هناك مضيفات متعددة (وسيط) بين مجموعات كافكا ، وسيكون لكل وسيط وسيط. له معرف فريد للتمييز. يمكن تحديد هذا المعرف يدويًا في ملف التكوين ويمكن إنشاءه تلقائيًا.

يمكن لـ Kafka التعاون مع Broker.id.generation.enable و Reserved.broker.max.id لإنشاء Broker.id جديد.

broker.id.generation.enseed يتم استخدام المعلمات لتكوين ما إذا كنت تريد فتح وظيفة الوسيط التلقائي. يحتوي الوسيط التلقائي. على قيمة افتراضية ، وهي 1000 مرة افتراضيًا ، مما يعني أن الوسيط التلقائي الذي يولد تلقائيًا يبدأ افتراضيًا من 1001.

ستقوم Kafka بتسجيل عقدة مؤقتة لنفس معرف الوسيط ضمن مسار /الوسطاء /IDS في ZookeEper عند البدء. يعتمد فحص صحة كافكا على هذه العقدة. عندما ينضم الوسيط إلى المجموعة أو يخرج من المجموعة ، سيتم إخطار هذه المكونات.

• إذا كنت ترغب في بدء وسيط آخر مع نفس المعرف ، فستحصل على خطأ -سيحاول الوسيط الجديد التسجيل ، لكنه لن ينجح ، لأن هناك بالفعل وسيطًا له نفس الهوية في Zookeeper.

• سيتم توصيل وسيط من Zookeeper من Zookeeper في هذا الوقت عندما يكون الوسيط هو التوقف أو التقسيم أو إعادة تدوير القمامة على المدى الطويل. في هذا الوقت ، ستتم إزالة العقدة المؤقتة التي أنشأها الوسيط من Zookeeper في هذا الوقت. سيتم إخبار مكون Kafka في قائمة الوسيط أنه تمت إزالة الوسيط.

• عند إيقاف تشغيل الوسيط ، ستختفي العقد المقابلة لها أيضًا ، لكن معرفه سيستمر في الوجود في هياكل البيانات الأخرى ، كما هو الحال في قائمة الموضوعات ، نسخ قائمة النسخ أدناه. بعد إغلاق وسيط تمامًا ، إذا كنت تستخدم نفس المعرف لبدء وسيط جديد آخر ، فسيتم الانضمام إلى المجموعة على الفور ولديه نفس القسم وموضوع الوسيط القديم.

دور وحدة التحكم في الوسيط

عندما كنا نتحدث عن إعادة توازن Kafka من قبل ، ذكرنا منسق المجموعة ومسؤولًا عن تنسيق العلاقة بين المجموعات. ثم يوجد أيضًا عنصر تحكم بين الوسيط ، وهو المكون الأساسي في Kafka. يتمثل دورها الرئيسي في إدارة وتنسيق مجموعة Kafka بأكملها بمساعدة ZookeEper. يمكن تسمية كل وسيط في الكتلة ، ولكن بعد إطلاق مجموعة Kafka ، سيصبح وسيط واحد فقط وحدة تحكم. نظرًا لأن مجموعة kafka تعتمد على مجموعة Zookeeper ، فمن الضروري أولاً تقديم ماهية Zookeeper. يمكنك الرجوع إلى مقالة المؤلف (Zookeeper ليس فقط مركز التسجيل ، ما الذي تعرفه؟) ، من السهل أن تكون بسيطًا. قم بتكوين مشكلة العقد Znode.

يتم حفظ بيانات Zookeeper على العقدة. تسمى كل عقدة أيضًا Znode. عقدة Znode هي بنية ملف على شكل شجرة. إنه يشبه مسار ملف نظام التشغيل Linux. عقدة الجذر لـ zookeeper هي /.

يمكن تقسيم Znode إلى عقد مؤقتة والعقد المستمرة بناءً على استمرار البيانات. لن تختفي العقدة المتينة بسبب التغييرات في حالة Zookeeper ، ولكن العقدة المؤقتة ستختفي تلقائيًا مع إعادة تشغيل Zookeeper.

تحتوي عقدة Znode على آلية مراقبة: عندما تتغير البيانات ، ستنتج ZookeEper حدث مراقب وإرساله إلى العميل. تعد آلية الاستماع الخاصة بـ Watcher ميزة مهمة للغاية في ZookeEper. استنادًا إلى العقد التي تم إنشاؤها على ZookeEper ، يمكننا ربط أحداث المراقبة على هذه العقد ، مثل تغيير بيانات العقد ، وحذف العقدة ، وتغيير حالة node الفرعي. وظائف مثل الأقفال الموزعة ، و يمكن تنفيذ إدارة الكتلة بناءً على Zookeeper.

انتخاب وحدة التحكم

قواعد وحدة تحكم الانتخابات الحالية في Kafka هي: الوسيط الأول في مجموعة Kafka يقوم بإنشاء وحدة تحكم وحدة تحكم عن طريق إنشاء عقدة /وحدة تحكم مؤقت في Zookeeper. سيحاول الوسطاء الآخرون أيضًا إنشاء هذه العقدة عند البدء ، ولكن نظرًا لأن هذه العقدة موجودة بالفعل ، عندما تريد إنشاء /تحكم العقد لاحقًا ، ستتلقى وجود عقدة غير طبيعي. سيقوم البكر الآخرون بعد ذلك بتسجيل كائن ساعة Zookeeeper على وحدة التحكم هذه. عندما تتغير العقد/وحدة التحكم ، سيتلقى الوسطاء الآخرون إشعارًا بتغيير العقدة. يمكن أن تضمن هذه الطريقة وجود وحدة تحكم واحدة فقط. ثم يجب أن تكون هناك مشكلة مع عقدة منفصلة فقط ، أي مشكلة واحدة.

إذا تم إغلاق وحدة التحكم أو فصل الرابط مع Zookeeper ، فستختفي العقدة المؤقتة على Zookeeper. بعد العقد الأخرى في المجموعة ، تلقت الأخبار التي تفيد بأن كائن الساعة يرسل وحدة التحكم في وضع عدم الاتصال ، ستحاول عقد الوسيط الأخرى أن تجعل نفسها وحدة تحكم جديدة. تتوافق قواعد إنشاء العقد الأخرى مع مبادئ العقدة الأولى. سيصبح الوسيط ، الذي هو أول من ينشئ عقدة تحكم في Zookeeper ، وحدة تحكم جديدة ، ثم تحصل العقد الأخرى على وجود وجود العقدة ثم قم بإنشاء كائن ساعة على عقدة وحدة التحكم الجديدة للمراقبة.

دور وحدة التحكم

كثيرا ، ما هو السيطرة؟ ما هو دور وحدة التحكم؟ أو ما الذي يتم تصميم هذا المكون من وحدة التحكم للقيام به؟ لا تقلق ، دعنا نتحدث عن ذلك بعد ذلك.

تم تصميم Kafka كوحدة تحكم متعددة الفرات لآلة الحالة التناظرية ، والتي يمكن أن تكون بمثابة ما يلي

• وحدة التحكم تعادل مدير القسم (وحدة تحكم الوسيط) في القسم (الكتلة) ، والتي تستخدم في أعضاء قسم الإدارة (الوسيط)

• وحدة التحكم هي شاشة لجميع الوسيط ، والذي يستخدم لمراقبة الوسيط عبر الإنترنت وغير متصل

• بعد الوسيط لأسفل ، يمكن للمراقب اختيار زعيم القسم الجديد

• يمكن لوحدة التحكم إرسال رسائل مع القائد الجديد الذي حدده الوسيط

يمكن تقسيم التجزئة إلى ما يلي في الساعة 5

• إدارة الموضوع: يمكن أن تساعدنا وحدة التحكم في Kafka في إكمال تشغيل إنشاء وزيادة تقسيم موضوع Kafka. باختصار ، لديها أعلى ممارسة للقسم.

kafka-topics

• : kafka-reassign-partitions

• Prefered : Preferred Kafka Broker Leader

• : brokerbroker broker

• : broker broker

broker ZooKeeper broker Leader Leader Leader Follower Leader Follower Leader Follower Leader

broker broker ID broker broker broker

broker controller

broker controller Kafka كما هو مبين أدناه

• broker broker broker broker broker

• ISR

• Preferred

Kafka ZooKeeper ZooKeeper ZooKeeper

broker controller

ZooKeeper /brokers/ids broker broker controller broker controller kafka Fail Over كما هو مبين أدناه

broker1 controller broker1 ZooKeeper Watch broker1 brokers controller broker3 ZooKeeper controller broker1 - > broker3broker3 ZooKeeper

ZooKeeper broker

broker controller

Kafka 0.11 Kafka controller

• controller

• broker

• controller I/O

• controller ReentrantLock

broker controller

Kafka 0.11 Kafka controller كما هو مبين أدناه

Event Executor Thread Event Queue Controller context

ZooKeeper ZooKeeper API ZooKeeper 10

broker controller ماذا يعني ذلك؟ broker produce controller StopReplica produce produce StopReplica

Kafka Kafka Kafka Kafka (Replication)/

يستخدم Kafka السمة لتنظيم البيانات. يتم تقسيم كل سمة إلى عدة أقسام. سيتم نشر الأقسام على العديد من البكر. سيكون لكل قسم نسخ متعددة ، لذلك سيتم تخزين النسخة على الوسيط. قد يوفر الوسيط عشرات الآلاف من النسخ. الشكل أدناه هو نسخة من نسخة

كما هو موضح في الشكل أعلاه ، من أجل رسم اثنين من الخبراء ، يشير كل وسيط إلى الأخبار التي تنقذ موضوعًا ، و 0 هو رائد في الوسيط 1. نسخة من سمة A من Broker2. بنفس الطريقة ، فإن موضوع القسم 1 هو نفسه.

يتم تقسيم نوعين من أنواع النسخ إلى نوعين: أحدهما نسخة (قائد) ، والآخر عبارة عن نسخة (تابع).

نسخة زعيم

يجب على كافكا انتخاب نسخة عند إنشاء قسم. نسخة من هذه الانتخابات هي نسخة من القائد القائد.

نسخة المتابعين

تسمى نسخة نسخة الزعيم نسخة المتابعين ، ولا يقدم المتابع خدمات للعالم الخارجي. فيما يلي طريقة عمل نسخة القائد

تحتاج إلى الانتباه إلى النقاط التالية

• في كافكا ، لا يتم توفير نسخة المتابعين أيضًا بواسطة نسخة المتابعين. وهذا يعني أنه لا يمكن لأي نسخة من المتابع الاستجابة لطلب المستهلكين والمنتجين. تتم معالجة جميع الطلبات بواسطة نسخة الزعيم. بمعنى آخر ، يجب إرسال جميع الطلبات إلى الوسيط حيث توجد نسخة الزعيم.

• عندما تراجع الوسيط الذي تراجع فيه نسخة الزعيم ، تعتمد Kafka على وظيفة المراقبة التي توفرها Zookeeper لإدراكها في الوقت الفعلي ، وتبدأ جولة جديدة من الانتخابات ، واختيار واحدة كقائد من نسخة المتابعين. إذا قام وسيط القمامة بإعادة تشغيل نسخة من القسم ، فسيتم إعادة الانضمام إلى أتباع.

مهمة أخرى للزعيم هي معرفة دولة التابع التي تتوافق مع نفسه. من أجل ضمان حالة القائد المتسقة ، حاول المتابعون نسخ الرسالة من القائد قبل وصول الأخبار الجديدة. من أجل الحفاظ على الاتساق مع القائد ، بدأ المتابع طلب الحصول على بيانات إلى القائد. هذا الطلب هو نفسه المعلومات التي أرسلها المستهلكون لقراءة الرسالة.

إن عملية إرسال رسالة إلى القائد مثل هذا. رسالة الطلب الأولى 1 ، ثم تلقي الرسالة 1. بعد الوصول إلى الطلب 1 ، أرسل الطلب 2. قبل استلام القائد ، سيتم إرسال المتابع إلى المتابع ، المتابع سيتم إرسالها إلى المتابع ، سيتم إرسال المتابع إلى المتابع. لن يستمر في إرسال الرسائل. هذه العملية كما يلي

لن تستمر نسخة التابع في إرسال الرسائل قبل تلقي رسالة الاستجابة ، وهو أمر مهم. من خلال التحقق من أحدث الإزاحة التي يتطلبها كل أتباع ، سيعرف القائد تقدم كل أتباع. إذا لم يطلب المتابع أي رسالة خلال 10s ، أو على الرغم من أن المتابع قد أرسل الطلب ، فلا توجد رسالة خلال 10s ، وسيتم اعتبارها غير متزامنة. إذا لم تتم مزامنة نسخة مع الزعيم ، فبعد سقوط الزعيم ، لن تسمى هذه النسخة القائد ، لأن أخبار هذه النسخة ليست كلها.

على العكس من ذلك ، إذا كانت الرسالة المتزامنة المتزامنة تتفق مع أخبار نسخة الزعيم ، فإن نسخة هذا المتابع تسمى أيضًا نسخة متزامنة. وبعبارة أخرى ، إذا سقط القائد ، يمكن فقط تسمية نسخ متزامنة.

لقد قلنا الكثير عن آلية النسخ ، فما هي فوائد آلية النسخ؟

• بعد رؤية أخبار الكتابة على الفور ، بعد استخدام واجهة برمجة تطبيقات المنتج لكتابة رسالة إلى القسم ، يمكن للمستهلك قراءة الرسالة المكتوبة للتو الآن.

• ماذا يعني إدراك قوة الرسالة؟ إنها الرسالة التي تم إنشاؤها بواسطة المنتج. عندما يستهلك المستهلكون ، سترى الرسالة في كل مرة ، ولن يكون هناك موقف لا توجد فيه الأخبار

نسخة متزامنة ونسخة غير متزامنة

عندما كنت أدرس آلية النسخ ، كان لدي سؤال. بما أن نسخة الزعيم ونسخة المتابعين يتم إرسالها ، فهذه طريقة نسخ متزامنة. فلماذا يقال أنه عندما يتم مزامنة أتباع المتابعين مع نسخة من نسخة الزعيم ، نسخة من القائد هي نسخة من نسخة القائد. ماذا عن العمليات غير المتزامنة؟

أعتقد أن هذا هو الحال. بعد أن حفظ نسخة المتابعين الرسالة في السجل المحلي بعد نسخة الزعيم. في هذا الوقت ، سيمنح المتابع الزعيم نسخة من الرد. بعد نسخة من جميع المتابعين مكتوب بنجاح ، سيعود إلى الأخبار إلى المنتج. إن النسخ المتماثل غير المتزامن هو أن نسخة القائد لا تحتاج إلى الاهتمام بما إذا كانت نسخة المتابعين مكتوبة بنجاح. طالما أن نسخة الزعيم تنقذ الرسالة إلى السجل المحلي ، فسوف يعود إلى الأخبار للكتابة بنجاح. فيما يلي عملية التكرار المتزامن والتكرار غير المتزامن

ينسخ

• المنتج يخطر قادة تحديد هوية Zookeeper

• كتب المنتج رسالة إلى القائد

• بعد تلقي الرسالة ، سيقوم القائد بكتابة الرسالة إلى السجل المحلي

• سوف يسحب المتابعون الرسالة من القائد

• كتب المتابع إلى السجل المحلي

• يرسل المتابع الأخبار إلى القائد

• سيتلقى القادة رسائل يرسلها جميع المتابعين

• يرسل القائد رسالة إلى المنتج إلى المنتج

تكرار غير متزامن

الفرق من النسخ المتماثل المتزامن هو أنه بعد الكتابة إلى السجل المحلي ، يرسل القائد مباشرة إلى العميل لكتابة رسالة ناجحة إلى العميل ، وليس هناك حاجة لانتظار جميع المتابعين لنسخها.

ISR

تحتفظ كافكا ديناميكيًا بمجموعة من الحالة المتزامنة (مجموعة من النسخ المتماثلة في المزامنة) ، المشار إليها باسم ISR ، هي أيضًا مفهوم مهم للغاية. إن بيانات نسخة القائد تعادل مجرد نسخ هذه العملية. Ctrl-C + يجب أن تكون Ctrl-V على دراية بها. فهل يكون عدد النسخ في مجموعة ISR هو نفس عدد نسخ القائد؟ هذا ليس بالضرورة. أساس الحكم هو قيمة المعلمة remlica.lag.time.max.ms في الوسيط. معنى هذه المعلمة هو أطول فترة زمنية لنسخة المتابعين من نسخة الزعيم.

الوقت الافتراضي لمعلمة REPLICA.LAG.TIME.MAX.MS هي 10 ثوانٍ. إذا لم يتجاوز أتباع أتباع المتابعين 10 ثوانٍ ، فإن كافكا يعتقد أن القادة والأتباع متزامنين. حتى في هذا الوقت ، فإن الرسالة المخزنة في نسخة المتابعين أقل من نسخة القائد. إذا كانت نسخة التابع ستتخلف عن نسخة الزعيم لأكثر من 10 ثوان ، فسيتم إزالة نسخة المتابعين من ISR. إذا اشتعلت النسخة ببطء مع تقدم القائد ، فيمكن رفضها إلى ISR. يوضح هذا أيضًا أن ISR عبارة عن مجموعة من التعديلات الديناميكية ، وليس ثابتًا دون تغيير.

انتخابات زعيم نجسة

نظرًا لأنه يمكن تعديل ISR ديناميكيًا ، فإن مجموعة ISR ستحدث حتماً. نظرًا لأن نسخة القائد يجب أن تظهر في مجموعة ISR ، فإن مجموعة ISR فارغة ولا مفر منها أن نسخة القائد معلقة أيضًا ، لذلك في هذا الوقت ، تحتاج كافكا إلى إعادة - انتخب زعيمًا جديدًا ، فكيف ينتخب؟ أنت الآن بحاجة إلى تغيير رأيك. قلنا أن مجموعة ISR يجب أن تكون نسخة متزامنة مع القائد ، لذلك يجب ألا تكون النسخة في مجموعة ISR عبارة يتبع قائمة ISR. ستخسر النسخة بعض الأخبار. إذا قمت بتشغيل المعلمة جانب الوسيط على عاتق. وتسمى هذه الانتخابات أيضا انتخابات القائد النجس.

CAP Unclean Kafka

Unclean

Kafka

broker // HTTP HTTP HTTP - > - > - > - >

HTTP Kafka TCP Socket

Kafka Kafka (Reactor)Reactor

Kafka broker SocketServerSocketServer TCP Socket

• Request type API Key

• Request versionbroker

• Correlation ID ---

• Client ID ---

broker Acceptor Processor() Processor num.network.threads 3 broker 3

Acceptor Processor -

After the PROCESSOR network thread pool receives the message sent by the customer and other Broker, the network thread pool will put the message in the request queue. Note that this is a shared request queue, because the network thread pool is multi -threaded mechanism, so the message of the request queue It is a multi -threaded area, and then processed by the IO thread pool. It is determined according to the type of message. For example, the product request will write the message into the log log. Read الرسالة.IOIO Purgatory Purgatory

IO broker num.io.threads 8 broker 8 IO

Kafka acks

acks = 1acks = 0 acks = all

acks all (Purgatory)

broker broker Kafka Kafka

10 bug bug 10 bug تداخل تداخل كما هو مبين أدناه

--- > replica.lag.time.max.ms

broker broker broker Kafka broker

broker broker

في ظل الظروف العادية ، يقوم العميل بتخزين هذه المعلومات ويرسل مباشرة طلبات الإنتاج والطلبات المقابلة إلى الوسيط المستهدف. يجب أن يتم تحديث هذه التخزين المؤقت في أوقات أخرى لتكوينها باستخدام metadata.max.age.ms. يتغيرون. على سبيل المثال ، بعد إضافة الوسيط الجديد ، سيؤدي إلى توازن شديد ، وسيتم نقل بعض النسخ إلى الوسيط الجديد. في هذا الوقت ، إذا تلقى العميل خطأً ليس هو القائد ، فإن العميل يقوم بتحديث ذاكرة التخزين المؤقت لـ Meta -Data قبل إرسال الطلب.

عملية توازن ثقيل كافكا

أنا حقيقي ، وأنا يكفي لقراءة هذا المقال عن كافكا. عندما أصف وصف المستهلكين ، وصلت العلاقة بين مجموعات المستهلكين والأرصدة الثقيلة. لقد توصلت مثيل المثيل إلى اتفاق بشأن استهلاك قسم الموضوع.

نحن نعلم أن مجموعة المستهلك يجب أن يكون لديها منسق المجموعة ، ويتم الانتهاء من عملية التوازن الثقيل بمساعدة المنسق.

هنا تحتاج إلى إعلان الشروط التي حدثت توازن التوازن أولاً

• أي موضوع يتغير اشتراك المستهلك

• يتغير عدد المستهلكين

• يتغير عدد الأقسام

• إذا قمت بالاشتراك في موضوع لم يتم إنشاؤه بعد ، يحدث التوازن الثقيل عند إنشاء السمة. إذا كان الموضوع الذي اشتركت في حذفه ، فسيحدث توازن ثقيل

• يعتبر منسق المجموعة أن المستهلكين قد ماتوا ، والذي قد يكون بسبب انهيار المستهلكين أو في حالة الجري لفترة طويلة. نبضات ، مما قد يؤدي أيضًا إلى توازن متوازن.

قبل فهم التوازن الثقيل ، تحتاج إلى معرفة هاتين الحرفين

المنسق: منسق المجموعة هو وسيط يمكنه تلقي رسائل نبضات من مجموعات المستهلكين من مجموعة المستهلك. في أول إصدار ، تم تخزين معلومات البيانات الوصفية في Zookeeper ، ولكن تم تخزين معلومات البيانات الوصفية الحالية في الوسيط. يجب أن تتم مزامنة كل مجموعة مستهلك مع منسق المجموعة في المجموعة. عندما يتم تنفيذ جميع القرارات في عقدة التطبيق ، يمكن لمنسق المجموعة تلبية طلب JoingRoup وتوفير معلومات البيانات الوصفية حول مجموعات المستهلكين ، مثل التخصيص والإزاحة. يحق لمنسق المجموعة الحق في معرفة نبضات جميع المستهلكين. هناك أيضًا دور في مجموعة المستهلكين وهو الرائد. انتبه لتمييزه بنسخة الزعيم ووحدة تحكم كافكا. القائد هو دور القرار في المجموعة ، لذلك إذا سقط القائد ، فإن منسق المجموعة له الحق في طرد جميع المستهلكين. لذلك ، فإن السلوك المهم للغاية لمجموعة المستهلك هو قائد الانتخابات وقراءة وكتابة معلومات البيانات الوصفية المتعلقة بالتخصيص والأقسام مع المنسق.

قادة المستهلكين: هناك قائد في كل مجموعة مستهلكين. إذا توقف المستهلكون عن إرسال دقات القلب ، فإن المنسقين سيؤديون إلى توازن كبير.

قبل فهم التوازن الثقيل ، تحتاج إلى معرفة ماهية آلة الحالة

صمم كافكا مجموعة من آلة الحالة لمساعدة المنسق على إكمال عملية توازن الوزن بالكامل. هناك خمس حالات رئيسية لآلات الدولة الاستهلاكية. فهي فارغة ، ميتة ، تحضير ، إكمال وثبات.

بعد فهم معنى هذه الحالات ، دعونا نستخدم بعض المسارات للتعبير عن دوران حالة المستهلك

كانت مجموعة المستهلكين في الحالة الفارغة في البداية. عندما تم فتح التوازن الثقيل ، سيتم وضعه في حالة التحضير وانتظر المستهلك الجديد. بمجرد انضمام المستهلكين الجدد ، ستكون مجموعة المستهلكين في حالة الانتهاء. مع انضمام المستهلكين الجدد إلى المجموعة أو المغادرة ، سيؤديون إلى توازن شديد ، وحالة المستهلكين قيد الإعداد. تم تحديد آلية الانتظار ويتم الانتهاء من التوزيع ، وبالتالي فإن المخطط الانسيابي مثل هذا

على أساس الرقم أعلاه ، عندما تصل مجموعة المستهلك إلى الحالة المستقرة ، بمجرد انتهاء صلاحية المستهلك/النبض/النبض ، يتم ظهور حالة مجموعة المستهلك في التحضير. ثم مخطط انسيابي مثل هذا.

على أساس الرقم أعلاه ، بعد أن تكون مجموعة المستهلكين في حالة التحضير ، من المؤسف. لم يلعب أحد ، وقد غادر جميع المستهلكين. في هذا الوقت أو تم تحديثه ، فإن مجموعة المستهلكين في حالة ميتة . هذا هو المخطط الانسيابي مثل هذا

على أساس الرقم أعلاه ، قمنا بتحليل التوازن الثقيل للمستهلكين ، وتحت أي حالة من حالة النزوح من قسم الموضوع في أي حالة تحت أي حالة من التحضير أو الإكمال أو الاستقرار ، ستكون المجموعة مباشرة في الدولة الميتة. جميع مساراتها على النحو التالي.

تحتاج إلى الانتباه إلى نقطتين:

بشكل عام ، تشير إزاحة XX المطلوبة في XXX Millisecond إلى أن Kafka من المحتمل أن تحذف بيانات الإزاحة للمجموعة باستثناء المجموعة في الحالة الفارغة ، وسوف تؤدي تشغيل حذف الإزاحة الزائد. لقد تعلمنا حول تحول حالة مجموعة المستهلك أعلى من عملية التوازن الثقيل. نبدأ في تقديم عملية إعادة التوازن. يمكن رؤية عملية التوازن الثقيل من جانبين: المستهلكين وأطراف المنسق. المجموعة وانتظر خطة تخصيص قائد الانتظار. الطلبات المقابلة بعد هاتين الخطوتين هي Joingre و SyncGroup. عندما ينضم المستهلك الجديد إلى المجموعة ، سيرسل المستهلك طلب JoingRoup إلى المنسق. في هذا الطلب ، يحتاج كل عضو مستهلك إلى تقديم موضوع استهلاكه. لقد وصفنا أعلاه وصف منسق المجموعة أن الغرض من ذلك هو السماح للمنسق بجمع ما يكفي من معلومات البيانات الوصفية لتحديد استهلاك الاستهلاك. قائد المجموعة. في ظل الظروف العادية ، سيتصل المستهلك الأول الذي يرسل طلب JoingRoup تلقائيًا بالزعيم. تتمثل مهمة القادة في جمع معلومات الاشتراك لجميع الأعضاء ، ثم صياغة حلول توزيع استهلاك القسم المحددة بناءً على هذه المعلومات. كما هو مبين في الشكل

بعد انضمام جميع المستهلكين إلى معلومات البيانات الوصفية إلى القادة ، وضع القادة خطة توزيع وأرسلوا طلب SyncGroup إلى المنسق. كان المنسق مسؤولاً عن استراتيجية الاستهلاك في المجموعة الجماعية. يصف الشكل أدناه عملية طلب SyncGroup

عندما تلقى جميع الأعضاء خطة التوزيع بنجاح ، دخلت مجموعة المستهلك إلى الحالة المستقرة ، أي بدء عمل الاستهلاك الطبيعي.

من منظور المنسق ، فإن توازن الوزن من منظور المنسق لديه بشكل أساسي شروط الزناد التالية.

ينضم أعضاء جدد إلى المجموعة

يأخذ أعضاء المجموعة المبادرة للمغادرة

أعضاء المجموعة ينهارون ويتركون

قدم عضو المجموعة الإزاحة

دعنا نصفه بشكل منفصل. لنبدأ مع العضو الجديد ينضم إلى المجموعة لبدء العضو الجديد لدخول المجموعة. إن مشهد مجموعة المستهلك بصدد انتظار تخصيصه.

من هذا المنظور ، تشبه عملية المنسق المستهلكين ، ولكن فقط من منظور المستهلكين ، الآن من منظور القائد

يغادر أعضاء المجموعة المجموعة ويتركون مجموعة المستهلكين يشيرون إلى مثيل المستهلك الذين يدعون الطريقة الوثيقة لإخطار المنسق بنشاط. سيكون هناك طلب جديد هنا ليظهر طلبات مجموعة المغادرة. كما هو مبين أدناه

يشير انهيار أعضاء المجموعة إلى فشل خطير في حالات المستهلكين. الوقت التوقف أو عدم الاستجابة لفترة من الوقت. لا يمكن للمنسق استلام نبضات المستهلك ، وسيعتبره أعضاء المجموعة ينهارون. عادة ما يحتاج الناس إلى ذلك انتظر لفترة من الوقت لإدراك أن هذه المرة يتم التحكم فيها بشكل عام بواسطة معلمات المستهلك Session.timeout.ms. كما هو مبين أدناه

لم نعد نستخدم الرسومات لتقديم الإزاحة أثناء الرصيد الثقيل. بشكل عام ، بعد أن يرسل المستهلك طلب Jobroup ، يجب على المستهلكين في المجموعة تقديم إزاحة كل منهما ضمن النطاق الزمني المحدد ، ثم يقومون بتشغيل العادي العادي. طلب إرسال. إخلاء المسئولية: يساهم المؤلف هذا المقال ، وحقوق الطبع والنشر ملك للمؤلف. كمطور لسنوات عديدة ، بعد استخدام لغة GO ...