أقترح قراءة نص المحاضرة "Hadoop. ZooKeeper" من سلسلة "طرق المعالجة الموزعة لكميات كبيرة من البيانات في Hadoop"
ما هو ZooKeeper ، مكانه في نظام Hadoop البيئي. الكذبة حول الحوسبة الموزعة. مخطط نظام توزيع قياسي. صعوبة تنسيق الأنظمة الموزعة. مشاكل التنسيق النموذجية. المبادئ الكامنة وراء تصميم ZooKeeper. نموذج بيانات ZooKeeper. أعلام znode. الجلسات. واجهة برمجة تطبيقات العميل. العناصر الأساسية (التكوين ، عضوية المجموعة ، الأقفال البسيطة ، انتخاب القائد ، القفل بدون تأثير القطيع). العمارة ZooKeeper. ZooKeeper DB. زاب. معالج الطلب.
اليوم سوف نتحدث عن ZooKeeper. هذا الشيء مفيد جدا. مثل أي منتج Apache Hadoop ، له شعار. يصور شخص.
قبل ذلك ، تحدثنا بشكل أساسي عن كيفية معالجة البيانات هناك ، وكيفية تخزينها ، أي كيفية استخدامها بطريقة ما والعمل معها بطريقة ما. واليوم أود أن أتحدث قليلاً عن إنشاء تطبيقات موزعة. و ZooKeeper هو أحد تلك الأشياء التي تجعل الأمر سهلاً. هذا نوع من الخدمة مصمم لنوع من التنسيق لتفاعل العمليات في الأنظمة الموزعة ، في التطبيقات الموزعة.
تزداد الحاجة إلى مثل هذه التطبيقات يومًا بعد يوم ، وهذا ما تدور حوله الدورة التدريبية لدينا. من ناحية أخرى ، يتيح لك MapReduce وهذا الإطار الجاهز تسوية هذا التعقيد وتحرير المبرمج من كتابة العناصر الأولية مثل التفاعل وتنسيق العمليات. لكن من ناحية أخرى ، لا أحد يضمن أن هذا لن يتم على أي حال. لا تحل MapReduce أو أطر العمل الجاهزة الأخرى دائمًا محل بعض الحالات التي لا يمكن تنفيذها في هذه الحالة. بما في ذلك MapReduce نفسه ومجموعة من مشاريع Apache الأخرى ، فهي في الواقع تطبيقات موزعة أيضًا. ولتسهيل الكتابة ، كتبوا ZooKeeper.
مثل جميع التطبيقات المتعلقة بـ Hadoop ، تم تطويره بواسطة Yahoo! الآن هو أيضًا التطبيق الرسمي لـ Apache. لم يتم تطويره بنشاط مثل HBase. إذا ذهبت إلى JIRA HBase ، فهناك الكثير من المهام للأخطاء كل يوم ، والكثير من الاقتراحات لتحسين شيء ما ، أي أن الحياة في المشروع مستمرة باستمرار. و ZooKeeper ، من ناحية ، منتج بسيط نسبيًا ، ومن ناحية أخرى ، يضمن ذلك موثوقيته. وهو سهل الاستخدام للغاية ، ولهذا أصبح معيارًا في التطبيقات داخل نظام Hadoop البيئي. لذلك ، اعتقدت أنه سيكون من المفيد مراجعته لفهم كيفية عمله وكيفية استخدامه.
هذه صورة من محاضرة لدينا. يمكننا القول أنه متعامد مع كل ما درسناه حتى الآن. وكل ما هو مذكور هنا ، بدرجة أو بأخرى ، يعمل مع ZooKeeper ، أي أنها خدمة تستخدم كل هذه المنتجات. لا تكتب HDFS ولا MapReduce الخدمات المماثلة الخاصة بها والتي من شأنها أن تعمل خصيصًا لهم. وفقًا لذلك ، يتم استخدام ZooKeeper. ويبسط التطوير وبعض الأشياء المتعلقة بالأخطاء.
من أين يأتي كل هذا؟ يبدو أنهم أطلقوا تطبيقين بالتوازي على أجهزة كمبيوتر مختلفة ، وربطوها بسلك أو في شبكة ، وكل شيء يعمل. لكن المشكلة هي أن الشبكة غير موثوقة ، وإذا شممت حركة المرور أو نظرت إلى ما يحدث هناك على مستوى منخفض ، وكيف يتفاعل العملاء على الشبكة ، يمكنك غالبًا أن ترى أن بعض الحزم مفقودة أو مستاءة. ليس من أجل لا شيء أنهم توصلوا إلى بروتوكولات TCP التي تسمح لك بإنشاء جلسة معينة وتضمن تسليم الرسائل. ولكن على أي حال ، حتى TCP لا يستطيع الحفظ دائمًا. كل شيء له مهلة. قد تسقط الشبكة لبعض الوقت. يمكنها فقط أن ترمش. وكل هذا يؤدي إلى حقيقة أنه لا يمكنك الاعتماد على حقيقة أن الشبكة موثوقة. هذا هو الاختلاف الرئيسي بين كتابة التطبيقات المتوازية التي تعمل على جهاز كمبيوتر واحد أو على كمبيوتر واحد عملاق ، حيث لا توجد شبكة ، حيث يوجد ناقل تبادل بيانات أكثر موثوقية في الذاكرة. وهذا هو الاختلاف الأساسي.
من بين أشياء أخرى ، باستخدام الشبكة ، هناك دائمًا نوع من التأخير. يحتوي القرص أيضًا على ذلك ، لكن الويب به المزيد. الكمون هو نوع من وقت التأخير ، والذي يمكن أن يكون صغيرًا وهامًا جدًا.
هيكل الشبكة يتغير. ما هو الهيكل هو وضع معدات شبكتنا. توجد مراكز بيانات ، وهناك رفوف قائمة هناك ، وهناك شموع. كل هذا يمكن إعادة توصيله ونقله وما إلى ذلك. كل هذا يجب أن يؤخذ في الاعتبار أيضًا. عناوين IP تتغير ، التوجيه يتغير ، من خلاله لدينا حركة مرور. هذا يحتاج أيضا إلى أن يؤخذ في الاعتبار.
يمكن أن تتغير الشبكة أيضًا من حيث المعدات. من الناحية العملية ، أستطيع أن أقول إن مهندسي الشبكة لدينا مغرمون جدًا بتحديث شيء ما على الشموع بشكل دوري. فجأة ، تم إخراج برنامج ثابت جديد وهم غير مهتمين بشكل خاص ببعض مجموعة Hadoop. لديهم عملهم الخاص. بالنسبة لهم ، الشيء الرئيسي هو أن الشبكة تعمل. وفقًا لذلك ، يريدون إعادة تحميل شيء ما هناك ، لعمل وميض على أجهزتهم ، بينما يتغير الجهاز أيضًا بشكل دوري. كل هذا يجب أن يؤخذ في الاعتبار بطريقة ما. كل هذا يؤثر على تطبيقنا الموزع.
عادة ، يعتقد الأشخاص الذين يبدأون العمل بكمية كبيرة من البيانات ، لسبب ما ، أن الويب لا حدود له. إذا كان هناك ملف بعدة تيرابايت ، فيمكنك نقله إلى الخادم أو جهاز الكمبيوتر الخاص بك ، وفتحه باستخدام قط و شاهد. آخر من الأخطاء همة مشاهدة سجلات. لا تفعل ذلك أبدًا ، لأنه سيء. نظرًا لأن Vim يحاول تخزين كل شيء مؤقتًا ، فقم بتحميل كل شيء في الذاكرة ، خاصةً عندما نبدأ في التنقل عبر هذا السجل والبحث عن شيء ما. هذه أشياء منسية ، لكن تستحق التفكير فيها.
من الأسهل كتابة برنامج واحد يعمل على كمبيوتر واحد بمعالج واحد.
عندما ينمو نظامنا ، نريد أن نوازي كل هذا ، وأن نوازي ليس فقط على الكمبيوتر ، ولكن أيضًا على الكتلة. السؤال الذي يطرح نفسه - كيف تنسق هذا العمل؟ قد لا تتفاعل تطبيقاتنا مع بعضها البعض ، لكننا أطلقنا عدة عمليات بالتوازي على عدة خوادم. وكيف تراقب أن كل شيء يسير على ما يرام بالنسبة لهم؟ هم ، على سبيل المثال ، يرسلون شيئًا ما عبر الويب. يجب أن يكتبوا في مكان ما عن حالتهم ، على سبيل المثال ، إلى بعض قواعد البيانات أو إلى سجل ، ثم تجميع هذا السجل ثم تحليله في مكان ما. بالإضافة إلى ذلك ، يجب أن تأخذ في الاعتبار أن العملية كانت تعمل وتعمل ، وفجأة ظهر نوع من الخطأ فيها أو تعطلت ، فما مدى سرعة اكتشافنا لها؟
من الواضح أنه يمكن رصد كل هذا بسرعة. هذا جيد أيضًا ، لكن المراقبة أمر محدود يسمح لك بمراقبة بعض الأشياء على أعلى مستوى.
عندما نريد أن تبدأ عملياتنا في التفاعل مع بعضها البعض ، على سبيل المثال ، إرسال بعض البيانات لبعضها البعض ، فإن السؤال الذي يطرح نفسه أيضًا - كيف سيحدث هذا؟ هل سيكون هناك نوع من حالة السباق ، هل سيكتبون فوق بعضهم البعض ، هل ستصل البيانات بشكل صحيح ، هل هناك شيء مفقود على طول الطريق؟ من الضروري تطوير نوع من البروتوكول ، إلخ.
تنسيق كل هذه العمليات ليس بالأمر التافه. وهو يجبر المطور على الانتقال إلى مستوى أدنى وكتابة الأنظمة إما من نقطة الصفر أو ليس تمامًا من نقطة الصفر ، لكن الأمر ليس بهذه السهولة.
إذا توصلت إلى خوارزمية تشفير أو حتى نفذتها ، فاخذها وتخلص منها على الفور ، لأنه على الأرجح لن يعمل من أجلك. سيحتوي على الأرجح على مجموعة من الأخطاء التي نسيت توقعها. لا تستخدمه بأي حال من الأحوال لشيء خطير ، لأنه على الأرجح سيكون غير مستقر. نظرًا لأن جميع الخوارزميات الموجودة ، يتم اختبارها بمرور الوقت لفترة طويلة جدًا. يتم البحث عن الأخطاء من قبل المجتمع. هذه قضية منفصلة. وهو نفس الشيء هنا. إذا كان من الممكن عدم تنفيذ نوع من مزامنة العمليات بمفردك ، فمن الأفضل عدم القيام بذلك ، لأنه صعب للغاية ويقودك إلى مسار غير مستقر للبحث باستمرار عن الأخطاء.
اليوم نحن نتحدث عن ZooKeeper. من ناحية ، هو إطار عمل ، ومن ناحية أخرى ، هو خدمة تسهل على المطور الحياة وتجعل من السهل قدر الإمكان تنفيذ المنطق وتنسيق عملياتنا.
تذكر الشكل الذي قد يبدو عليه النظام الموزع القياسي. هذا ما تحدثنا عنه - هذا هو HDFS ، HBase. هناك عملية رئيسية تدير العمال وعمليات العبيد. إنه مسؤول عن تنسيق المهام وتوزيعها ، وإعادة تشغيل العمال ، وإطلاق مهام جديدة ، وموازنة العبء.
والشيء الأكثر تقدمًا هو خدمة التنسيق ، أي نقل مهمة التنسيق نفسها إلى عملية منفصلة ، بالإضافة إلى تشغيل نوع من النسخ الاحتياطي أو التوقف للماجستير بالتوازي ، لأن السيد قد يتعطل. وإذا سقط السيد ، فلن يعمل نظامنا. نحن نقوم بتشغيل النسخ الاحتياطي. يقول البعض أن المعلم يحتاج إلى نسخ احتياطي. يمكن أيضًا أن يُعهد بذلك إلى خدمة التنسيق. لكن في هذا المخطط ، ينسق المعلم نفسه العمال ، وهنا تنسق الخدمة نسخ البيانات.
الخيار الأكثر تقدمًا هو عندما تقوم خدمتنا بكل التنسيق ، كما هو الحال عادةً. يتحمل مسؤولية التأكد من أن كل شيء يعمل. وإذا لم ينجح شيء ما ، فإننا نتعرف عليه ونحاول التغلب على هذا الموقف. على أي حال ، لقد تركنا مع السيد ، الذي يتفاعل بطريقة ما مع العبيد ، يمكنه إرسال البيانات والمعلومات والرسائل وما إلى ذلك من خلال خدمة معينة.
هناك مخطط أكثر تقدمًا ، عندما لا يكون لدينا سيد ، تكون جميع العقد عبيدًا رئيسيًا ، ويختلفون في سلوكهم. لكن على الرغم من ذلك ، فهم بحاجة إلى التفاعل مع بعضهم البعض ، لذلك لا تزال هناك خدمة معينة لتنسيق هذه الإجراءات. على الأرجح ، فإن Cassandra ، التي تعمل وفقًا لهذا المبدأ ، تناسب هذا المخطط.
من الصعب تحديد أي من هذه المخططات يعمل بشكل أفضل. كل له ايجابيات وسلبيات.
ولا داعي للخوف من بعض الأشياء مع السيد ، لأنه ، كما تظهر الممارسة ، ليس عرضة للعطاء باستمرار. الشيء الرئيسي هنا هو اختيار الحل المناسب لاستضافة هذه الخدمة على عقدة قوية منفصلة بحيث يكون لديها موارد كافية بحيث ، إذا أمكن ، لا يستطيع المستخدمون الوصول إليها ، حتى لا يقتلوا هذه العملية عن طريق الخطأ. ولكن في الوقت نفسه ، في مثل هذا المخطط ، يكون من الأسهل بكثير إدارة العمال من العملية الرئيسية ، أي أن هذا المخطط أبسط من حيث التنفيذ.
وربما يكون هذا المخطط (أعلاه) أكثر تعقيدًا ، ولكنه أكثر موثوقية.
المشكلة الرئيسية هي الفشل الجزئي. على سبيل المثال ، عندما نرسل رسالة عبر الشبكة ، يحدث نوع من الحوادث ، ولن يعرف الشخص الذي أرسل الرسالة ما إذا كانت رسالته قد وصلت وما حدث على جانب المتلقي ، فلن يعرف ما إذا كانت الرسالة قد تمت معالجتها بشكل صحيح أي لن يتلقى أي تأكيد.
وفقًا لذلك ، يجب علينا معالجة هذا الوضع. وأبسط شيء هو إعادة إرسال هذه الرسالة والانتظار حتى نتلقى ردًا. في هذه الحالة ، لا يؤخذ في الاعتبار في أي مكان ما إذا كانت حالة جهاز الاستقبال قد تغيرت. ربما سنرسل رسالة ونضيف نفس البيانات مرتين.
يوفر ZooKeeper طرقًا للتعامل مع مثل هذه الإخفاقات ، مما يجعل الحياة أسهل بالنسبة لنا أيضًا.
كما ذكرنا سابقًا ، يشبه هذا كتابة البرامج متعددة الخيوط ، ولكن الاختلاف الرئيسي هو أنه في التطبيقات الموزعة التي نبنيها على أجهزة مختلفة ، فإن الطريقة الوحيدة للتفاعل هي الشبكة. في جوهرها ، هذه بنية لا تشارك. كل عملية أو خدمة يتم تشغيلها على جهاز واحد لها ذاكرتها الخاصة ، وقرصها الخاص ، ومعالجها الخاص ، والتي لا تشاركها مع أي شخص.
إذا كنا نكتب برنامجًا متعدد الخيوط على جهاز كمبيوتر واحد ، فيمكننا استخدام الذاكرة المشتركة لتبادل البيانات. لدينا تبديل السياق هناك ، يمكن للعمليات التبديل. هذا يؤثر على الأداء. من ناحية أخرى ، لا يوجد شيء من هذا القبيل في البرنامج على الكتلة ، ولكن هناك مشاكل في الشبكة.
وفقًا لذلك ، فإن المشاكل الرئيسية التي تنشأ عند كتابة الأنظمة الموزعة هي التكوين. نحن نكتب بعض التطبيقات. إذا كان الأمر بسيطًا ، فسنقوم بتشفير جميع أنواع الأرقام في الكود ، ولكن هذا غير مريح ، لأننا إذا قررنا أنه بدلاً من مهلة نصف ثانية ، فإننا نريد مهلة ثانية واحدة ، ثم نحتاج إلى إعادة ترجمة التطبيق ، قم بطرحها كلها مرة أخرى. إنه شيء واحد عندما يكون على جهاز واحد ، عندما يمكنك إعادة تشغيله ، وعندما يكون لدينا العديد من الأجهزة ، يتعين علينا نسخ كل شيء باستمرار. يجب أن نحاول جعل التطبيق قابلاً للتكوين.
نتحدث هنا عن التكوين الثابت لعمليات النظام. هذا ليس تمامًا ، ربما ، من وجهة نظر نظام التشغيل ، يمكن أن يكون تكوينًا ثابتًا لعملياتنا ، أي أنه تكوين لا يمكن أخذه وتحديثه ببساطة.
وهناك أيضًا تكوين ديناميكي. هذه هي المعلمات التي نريد تغييرها بسرعة حتى يتم التقاطها هناك.
ماهي المشكلة هنا؟ قمنا بتحديث التكوين ، وطرحناه ، وماذا في ذلك؟ قد تكون المشكلة من ناحية أننا طرحنا التكوين ، لكننا نسينا الشيء الجديد ، بقي التكوين هناك. ثانيًا ، بينما كنا نطرح ، تم تحديث التكوين في مكان ما ، ولكن لم يتم تحديثه في مكان ما. وأعيد تشغيل بعض عمليات تطبيقنا التي تعمل على نفس الجهاز بتكوين جديد ، وفي مكان ما مع التكوين القديم. يمكن أن يؤدي هذا إلى عدم توافق تطبيقنا الموزع من حيث التكوين. هذه المشكلة شائعة. بالنسبة للتكوين الديناميكي ، فهو أكثر ملاءمة ، لأنه من المفترض أنه يمكن تغييره بسرعة.
قضية أخرى هي عضوية المجموعة. لدينا دائمًا مجموعة من العمال ، ونريد دائمًا معرفة أي منهم على قيد الحياة وأي منهم مات. إذا كان هناك سيد ، فعليه أن يفهم أي العمال يمكن إعادة توجيههم إلى العملاء حتى يبدأوا العمليات الحسابية أو يعملون بالبيانات ، وأيهم لا يمكنهم ذلك. تظهر المشكلة باستمرار أنك بحاجة إلى معرفة من يعمل في مجموعتنا.
مشكلة نموذجية أخرى هي انتخاب الزعيم عندما نريد أن نعرف من هو المسؤول. أحد الأمثلة على ذلك هو النسخ المتماثل ، عندما يكون لدينا بعض العمليات التي تقبل عمليات الكتابة ثم نعيدها إلى عمليات أخرى. سيكون القائد ، وسيطيعه الباقون وسيتبعونه. من الضروري اختيار مثل هذه العملية بحيث لا لبس فيها للجميع ، حتى لا يحدث أن يخرج زعيمان.
هناك أيضا وصول حصري للطرفين. هنا المشكلة أكثر تعقيدًا. هناك شيء مثل كائن المزامنة (mutex) ، عندما تكتب برامج متعددة الخيوط وتريد الوصول إلى بعض الموارد ، على سبيل المثال ، إلى خلية ذاكرة ، لتكون محدودة ويتم تنفيذها بواسطة مؤشر ترابط واحد فقط. هنا ، يمكن أن يكون المورد شيئًا أكثر تجريدًا. ويجب أن تحصل التطبيقات المختلفة من العقد المختلفة لشبكتنا فقط على وصول حصري إلى هذا المورد ، وليس حتى يتمكن الجميع من تغييره أو كتابة شيء ما هناك. هذه هي أقفال ما يسمى.
يتيح لك ZooKeeper حل كل هذه المشكلات بدرجة أو بأخرى. وسأوضح بأمثلة كيف يتيح لك ذلك.
لا توجد اعداء الاولياء. عندما نبدأ في استخدام شيء ما ، فإن هذه البدائية لن تنتظر حدوث أي حدث. على الأرجح ، سيعمل هذا الشيء بشكل غير متزامن ، مما يسمح للعمليات بعدم تعليق الحالة التي تنتظرها. هذا شيء مفيد جدا.
تتم معالجة جميع طلبات العملاء بترتيب قائمة الانتظار العامة.
ويتمتع العملاء بفرصة تلقي إخطار حول التغييرات في بعض الحالات ، حول تغييرات البيانات ، قبل أن يرى العميل البيانات المتغيرة نفسها.
يمكن أن يعمل ZooKeeper في وضعين. الأول قائم بذاته ، على عقدة واحدة. هذا مفيد للاختبار. ويمكنه أيضًا العمل في وضع الكتلة ، على أي عدد من الخوادم. إذا كان لدينا مجموعة من 100 آلة ، فليس من الضروري أن تعمل على 100 آلة. يكفي تحديد عدد قليل من الأجهزة حيث يمكنك تشغيل ZooKeeper. ويعترف بمبدأ التوافر العالي. يحتفظ ZooKeeper بنسخة كاملة من البيانات في كل مثيل قيد التشغيل. سأخبرك لاحقًا كيف يفعل ذلك. إنه لا يكسر البيانات ولا يقسمها. من ناحية ، هذا ناقص أننا لا نستطيع تخزين الكثير ، من ناحية أخرى ، هذا ليس ضروريًا. إنها ليست مصممة لذلك ، إنها ليست قاعدة بيانات.
يمكن تخزين البيانات مؤقتًا من جانب العميل. هذا مبدأ قياسي حتى لا نسحب الخدمة ، ولا نحملها بنفس الطلبات. عادة ما يعرف العميل الذكي عن هذا ويخزنه مؤقتًا في المنزل.
على سبيل المثال ، لقد تغير شيء ما. هناك بعض التطبيقات. لقد اخترنا قائدًا جديدًا يكون مسؤولاً ، على سبيل المثال ، عن معالجة عمليات الكتابة. ونريد نسخ البيانات. أحد الحلول هو وضع دورة. ونستطلع خدماتنا باستمرار - هل تغير شيء ما؟ الخيار الثاني هو الأفضل. هذه آلية مراقبة تسمح لك بإخطار العملاء بأن شيئًا ما قد تغير. هذه طريقة أقل تكلفة من حيث الموارد وأكثر ملاءمة للعملاء.
العميل هو المستخدم الذي يستخدم ZooKeeper.
الخادم هو عملية ZooKeeper نفسها.
Znode هي الميزة الأساسية لـ ZooKeeper. يتم تخزين جميع znodes في الذاكرة بواسطة ZooKeeper ويتم تنظيمها في مخطط هرمي ، في شكل شجرة.
هناك نوعان من العمليات. الأول هو التحديث / الكتابة ، عندما تغير بعض العمليات حالة شجرتنا. الشجرة عامة.
ومن الممكن أن لا يفي العميل بطلب واحد ويتم قطعه ، ولكن يمكنه إنشاء جلسة يتفاعل معها مع ZooKeeper.
نموذج بيانات ZooKeeper يشبه نظام الملفات. هناك جذر قياسي ، ثم ذهبنا كما لو كان من خلال الدلائل التي تأتي من الجذر. ثم كتالوج المستوى الأول ، المستوى الثاني. كلها znodes.
يمكن لكل znode تخزين بعض البيانات ، وعادةً لا تكون كبيرة جدًا ، على سبيل المثال ، 10 كيلوبايت. ويمكن أن يكون لكل znode عدد من الأطفال.
تأتي Znodes في عدة أنواع. يمكن إنشاؤها. وعند إنشاء znode ، نحدد النوع الذي يجب أن ينتمي إليه.
هناك نوعان. الأول هو علم سريع الزوال. يعيش Znode في جلسة. على سبيل المثال ، أنشأ العميل جلسة. وبينما هذه الجلسة على قيد الحياة ، فإنها ستكون موجودة. هذا ضروري حتى لا تنتج شيئًا غير ضروري. كما أنه مناسب لمثل هذه اللحظات عندما يكون من المهم بالنسبة لنا تخزين البيانات الأولية في الجلسة.
النوع الثاني هو العلم المتسلسل. يقوم بزيادة العداد في طريقه إلى znode. على سبيل المثال ، كان لدينا دليل مع التطبيق 1_5. وعندما أنشأنا العقدة الأولى ، تلقت p_1 ، والثانية - p_2. وعندما نسمي هذه الطريقة في كل مرة ، نمر بالمسار الكامل ، مشيرين فقط إلى جزء من الفارغ ، وهذا الرقم يتزايد تلقائيًا ، لأننا نحدد نوع العقدة - متسلسل.
znode العادي. ستعيش إلى الأبد وستحمل الاسم الذي سنقوله لها.
شيء مفيد آخر هو علم المراقبة. إذا قمنا بتعيينه ، فيمكن للعميل الاشتراك في بعض الأحداث لعقدة معينة. سأوضح لاحقًا بمثال كيف يتم ذلك. يقوم ZooKeeper نفسه بإعلام العميل بتغيير البيانات الموجودة على العقدة. في الوقت نفسه ، لا تضمن الإخطارات وصول بعض البيانات الجديدة. يقولون فقط أن شيئًا ما قد تغير ، لذلك لاحقًا سيتعين عليك مقارنة البيانات على أي حال بمكالمات منفصلة.
وكما قلت ، يتم تحديد ترتيب البيانات بالكيلو بايت. ليست هناك حاجة لتخزين بيانات نصية كبيرة هناك ، لأن هذه ليست قاعدة بيانات ، هذا خادم لتنسيق الإجراءات.
سأخبرك قليلاً عن الجلسات. إذا كان لدينا عدة خوادم ، فيمكننا الانتقال بشفافية من خادم إلى خادم باستخدام معرف الجلسة. إنها مريحة جدًا.
كل جلسة لديها نوع من المهلة. يتم تحديد الجلسة من خلال ما إذا كان العميل سيرسل شيئًا ما إلى الخادم أثناء تلك الجلسة. إذا لم يرسل أي شيء أثناء المهلة ، تسقط الجلسة ، أو يمكن للعميل إغلاقها بنفسه.
لا يحتوي على العديد من الميزات ، ولكن يمكنك القيام بكل أنواع الأشياء باستخدام واجهة برمجة التطبيقات هذه. ينشئ الاستدعاء الذي رأيناه ينشئ znode ويأخذ ثلاثة معلمات. هذا هو المسار إلى znode ويجب أن يكون مؤهلاً من الجذر. وهذه أيضًا بعض البيانات التي نريد نقلها هناك. ونوع العلم. وبعد الخلق ، تعيد المسار إلى znode.
يمكن إزالة الثاني. الحيلة هنا هي أن المعلمة الثانية ، بالإضافة إلى المسار إلى znode ، يمكنك تحديد الإصدار. وفقًا لذلك ، سيتم حذف znode هذا إذا كان إصداره ، الذي مررناه ، يعادل الإصدار الموجود بالفعل.
إذا أردنا عدم التحقق من هذا الإصدار ، فإننا ببساطة نمرر الوسيطة "-1".
ثالثًا ، يتحقق من وجود znode. يعود صحيحًا إذا كانت العقدة موجودة ، خطأ إذا كان العكس.
ثم تظهر علامة المراقبة ، والتي تتيح لك ضبط المراقبة لهذه العقدة.
يمكنك تعيين هذه العلامة حتى على عقدة غير موجودة والحصول على إشعار عند ظهورها. هذا مفيد أيضًا.
بضع مكالمات أخرى احصل على البيانات. من الواضح أنه يمكننا الحصول على البيانات عن طريق znode. يمكنك أيضًا استخدام ساعة العلم. في هذه الحالة ، لن يتم تثبيته إذا لم يكن هناك عقدة. لذلك ، عليك أن تفهم أنها موجودة ، ثم تحصل على البيانات.
يوجد ايضا SetData. ها نحن نمرر الإصدار. وإذا مررناها ، فسيتم تحديث البيانات الموجودة على الرمز znode لإصدار معين.
يمكنك أيضًا تحديد "-1" لاستبعاد هذا الاختيار.
طريقة أخرى مفيدة هي getChildren. يمكننا أيضًا الحصول على قائمة بجميع znodes التي تنتمي إليها. يمكننا مشاهدة هذا عن طريق ضبط ساعة العلم.
والطريقة مزامنة يسمح بإرسال جميع التغييرات في وقت واحد ، وبالتالي ضمان حفظها وتغيير جميع البيانات بالكامل.
إذا قمت برسم تشابهات مع البرمجة التقليدية ، فعند استخدام طرق مثل الكتابة التي تكتب شيئًا ما على القرص ، وبعد أن تقوم بإرجاع استجابة لك ، فليس هناك ما يضمن أن لديك بيانات مكتوبة على القرص. وحتى عندما يتأكد نظام التشغيل من أن كل شيء قد تمت كتابته ، فهناك آليات في القرص نفسه حيث تمر العملية عبر مستويات المخزن المؤقت ، وبعد ذلك يتم وضع البيانات على القرص.
يتم استخدام المكالمات غير المتزامنة في الغالب. هذا يسمح للعميل بالعمل على طلبات مختلفة بالتوازي. يمكنك استخدام النهج المتزامن ، لكنه أقل إنتاجية.
العمليتان اللتان تحدثنا عنهما هما التحديث / الكتابة ، مما يغير البيانات. هذه هي إنشاء ، setData ، مزامنة ، حذف. والقراءة موجودة ، getData ، getChildren.
الآن بعض الأمثلة عن كيفية جعل الأوليات تعمل في نظام موزع. على سبيل المثال ، المتعلقة بتكوين شيء ما. ظهر عامل جديد. أضفنا سيارة ، وبدأنا العملية. وهناك ثلاثة أسئلة. كيف يطلب التكوين من ZooKeeper؟ وإذا أردنا تغيير التكوين ، فكيف نغيره؟ وبعد أن قمنا بتغييرها ، كيف حصل عليها العمال الذين حصلنا عليهم؟
في ZooKeeper ، يمكن القيام بذلك بسهولة نسبيًا. على سبيل المثال ، لدينا znode الشجرة. هناك عقدة لتطبيقنا هنا ، نقوم بإنشاء عقدة إضافية فيها ، والتي تحتوي على بيانات من التكوين. هذه قد تكون أو لا تكون معلمات منفصلة. نظرًا لأن الحجم صغير ، يكون حجم التكوين صغيرًا أيضًا ، لذلك من الممكن تخزينه هنا.
أنت تستخدم الطريقة احصل على البيانات للحصول على التكوين للعامل من العقدة. اضبط على صواب. إذا كانت هذه العقدة غير موجودة لسبب ما ، فسيتم إعلامنا بها عند ظهورها أو عند تغييرها. إذا أردنا أن نعرف أن شيئًا ما قد تغير ، فسنضبطه على صواب. وإذا تغيرت البيانات الموجودة في هذه العقدة ، فسنعرف عنها.
SetData. نقوم بتعيين البيانات ، بتعيين "-1" ، أي أننا لا نتحقق من الإصدار ، ونعتقد أن لدينا دائمًا نفس التكوين ، ولا نحتاج إلى تخزين العديد من التكوينات. إذا كنت بحاجة إلى تخزين الكثير ، فستحتاج إلى إضافة مستوى آخر. هنا نعتبر أنه الإصدار الوحيد ، لذلك نقوم بتحديث الأحدث فقط ، لذلك لا نتحقق من الإصدار. في هذه اللحظة ، يتلقى جميع العملاء الذين اشتركوا سابقًا إشعارًا بأن شيئًا ما قد تغير في هذه العقدة. وبعد استلامها ، يتعين عليهم أيضًا طلب البيانات مرة أخرى. يكمن الإخطار في حقيقة أنهم لا يتلقون البيانات نفسها ، ولكن فقط إشعار بالتغييرات. بعد ذلك ، يجب عليهم طلب بيانات جديدة.
الاستخدام الثاني للبدائية هو عضوية في المجموعة. لدينا تطبيق موزع ، لدينا مجموعة من العمال ونريد أن نفهم أنهم جميعًا في أماكنهم. لذلك ، يجب عليهم تسجيل أنفسهم بأنهم يعملون في تطبيقنا. ونريد أيضًا التعرف على جميع العاملين النشطين الموجودين لدينا حاليًا ، إما من عملية الماجستير أو من مكان آخر.
كيف لنا أن نفعل ذلك؟ بالنسبة للتطبيق ، نقوم بإنشاء عقدة العمال وإضافة مستوى فرعي هناك باستخدام طريقة الإنشاء. لدي خطأ في الشريحة. هنا تحتاج تسلسلي حدد ، ثم سيتم إنشاء جميع العمال واحدًا تلو الآخر. والتطبيق ، الذي يطلب جميع البيانات عن أبناء هذه العقدة ، يحصل على جميع العاملين النشطين.
إليك مثل هذا التنفيذ الرهيب لكيفية القيام بذلك في كود Java. لنبدأ من النهاية بالطريقة الرئيسية. هذا هو صفنا ، نحن نصنع طريقته. كحجة أولى ، نستخدم المضيف ، حيث نتواصل ، أي أننا نضعه كوسيطة. والحجة الثانية - اسم المجموعة.
كيف يجري الاتصال؟ هذا مثال بسيط لواجهة برمجة التطبيقات التي يتم استخدامها. كل شيء بسيط نسبيًا هنا. هناك فئة ZooKeeper قياسية. نعطيها المضيفين. وقم بتعيين مهلة ، على سبيل المثال ، 5 ثوان. ولدينا عضو مثل connectSignal. في جوهرها ، نقوم بإنشاء مجموعة من خلال المسار الذي تم تمريره. نحن لا نكتب البيانات هناك ، على الرغم من إمكانية كتابة شيء ما. والعقدة هنا من النوع الثابت. في الواقع ، هذه عقدة عادية عادية ستظل موجودة طوال الوقت. هذا هو المكان الذي تم فيه إنشاء الجلسة. هذا هو تنفيذ العميل نفسه. سيبلغ عميلنا بشكل دوري أن الجلسة على قيد الحياة. وعندما ننتهي من الجلسة ، ننتهي من الجلسة وهذا كل شيء ، تسقط الجلسة. هذا في حالة وقوع شيء ما معنا ، حتى يكتشف ZooKeeper ذلك ويقطع الجلسة.
كيفية قفل بعض الموارد؟ هنا كل شيء أكثر تعقيدًا إلى حد ما. لدينا مجموعة من العمال ، وهناك نوع من الموارد التي نريد قفلها. للقيام بذلك ، نقوم بإنشاء عقدة منفصلة ، على سبيل المثال ، تسمى lock1. إذا تمكنا من إنشائه ، فسنحصل على قفل هنا. وإذا لم نتمكن من إنشائها ، فسيحاول العامل الحصول على GetData من هنا ، وبما أن العقدة قد تم إنشاؤها بالفعل ، فإننا نضع مراقبًا هنا وفي اللحظة التي تتغير فيها حالة هذه العقدة ، سنعرف عنها هو - هي. ويمكننا أن نحاول الحصول على الوقت لإعادة إنشائه. إذا أخذنا هذه العقدة ، وأخذنا هذا القفل ، ثم بعد أن لم نعد بحاجة إلى القفل ، سنرفضه ، لأن العقدة موجودة فقط داخل الجلسة. تبعا لذلك ، سوف تختفي. وسيتمكن عميل آخر في جلسة أخرى من التقاط قفل على هذه العقدة ، أو بالأحرى ، سيتلقى إشعارًا بأن شيئًا ما قد تغير ويمكنه محاولة القيام بذلك في الوقت المناسب.
مثال آخر على كيفية اختيار القائد الرئيسي. هذا أكثر تعقيدًا بعض الشيء ، ولكنه أيضًا بسيط نسبيًا. ماذا لدينا هنا؟ هناك عقدة رئيسية تجمع كل العمال. نحاول الحصول على بيانات عن القائد. إذا حدث هذا بنجاح ، أي تلقينا بعض البيانات ، فسيبدأ عاملنا في اتباع هذا القائد. إنه يعتقد أن القائد موجود بالفعل.
إذا مات القائد لسبب ما ، على سبيل المثال ، سقط ، فإننا نحاول إنشاء قائد جديد. وإذا نجحنا ، يصبح العامل لدينا هو القائد. وإذا تمكن شخص ما في هذه اللحظة من إنشاء قائد جديد ، فإننا نحاول أن نفهم من هو ثم نتبعه.
هنا يظهر ما يسمى بتأثير القطيع ، أي تأثير القطيع ، لأنه عندما يموت القائد ، يصبح الشخص الأول في الوقت المناسب هو القائد.
عند الاستيلاء على مورد ، يمكنك محاولة استخدام نهج مختلف قليلاً ، على النحو التالي. على سبيل المثال ، نريد الحصول على قفل ، ولكن بدون تأثير هيرت. سيتكون من حقيقة أن طلبات التطبيق لدينا قوائم بجميع معرفات العقدة لعقدة موجودة بالفعل مع قفل. وإذا كانت العقدة التي أنشأنا لها القفل قبل ذلك هي الحد الأدنى للمجموعة التي تلقيناها ، فهذا يعني أننا استولنا على القفل. نتحقق من أننا حصلنا على قفل. كشيك ، سيكون هناك شرط بأن المعرف الذي تلقيناه عند إنشاء قفل جديد هو الحد الأدنى. وإذا تلقينا ، فإننا نعمل أكثر.
إذا كان هناك بعض المعرف أقل من القفل الخاص بنا ، فإننا نضع مراقبًا في هذا الحدث وننتظر إشعارًا حتى يتغير شيء ما. وهذا يعني أننا تلقينا هذا القفل. وحتى تسقط ، لن نصبح الحد الأدنى للمعرف ولن نحصل على الحد الأدنى من القفل ، وبالتالي سنكون قادرين على الإغلاق. وإذا لم يتم استيفاء هذا الشرط ، فإننا نذهب على الفور إلى هنا ونحاول الحصول على هذا القفل مرة أخرى ، لأنه كان من الممكن أن يتغير شيء ما خلال هذا الوقت.
مما يتكون ZooKeeper؟ هناك 4 أشياء رئيسية. هذه هي معالجة العمليات - الطلب. وكذلك ZooKeeper Atomic Broadcast. يوجد سجل تنفيذ حيث يتم تسجيل جميع العمليات. وقاعدة البيانات المكررة في الذاكرة نفسها ، أي قاعدة البيانات نفسها ، حيث يتم تخزين هذه الشجرة بأكملها.
من الجدير بالذكر أن جميع عمليات الكتابة تمر عبر معالج الطلبات. وتذهب عمليات القراءة مباشرة إلى قاعدة البيانات في الذاكرة.
تم نسخ قاعدة البيانات نفسها بالكامل. تخزن جميع مثيلات ZooKeeper نسخة كاملة من البيانات.
من أجل استعادة قاعدة البيانات بعد حدوث عطل ، يوجد سجل تنفيذ. من الممارسات المعتادة كتابة البيانات هناك قبل أن تدخل في الذاكرة ، بحيث في حالة حدوث عطل ، يمكن إعادة تشغيل هذا السجل واستعادة حالة النظام. ويتم أيضًا تطبيق لقطات قاعدة البيانات الدورية.
ZooKeeper Atomic Broadcast هو شيء يستخدم للحفاظ على البيانات المنسوخة.
يختار ZAB داخليًا قائدًا من وجهة نظر عقدة ZooKeeper. العقد الأخرى تصبح أتباعها ، في انتظار بعض الإجراءات منها. إذا وصلت السجلات إليهم ، فسيتم إعادة توجيههم جميعًا إلى القائد. يقوم بإجراء عملية الكتابة مسبقًا ثم يرسل رسالة حول ما تغير إلى أتباعه. هذا ، في الواقع ، يجب أن يتم بشكل ذري ، أي أن عملية التسجيل والبث لكل هذا يجب أن تتم بشكل ذري ، وبالتالي ضمان اتساق البيانات.
يقوم بمعالجة طلبات الكتابة فقط. وتتمثل مهمتها الرئيسية في تحويل العملية إلى تحديث للمعاملات. هذا طلب معد خصيصًا.
وهنا تجدر الإشارة إلى أن عدم القدرة على إجراء التحديثات لنفس العملية مضمون. ما هذا؟ هذا الشيء ، إذا قمت بتشغيله مرتين ، فسيكون له نفس الحالة ، أي أن الطلب نفسه لن يتغير من هذا. وتحتاج إلى القيام بذلك حتى في حالة حدوث عطل ، يمكنك إعادة تشغيل العملية ، وبالتالي تغيير التغييرات التي سقطت في الوقت الحالي. في هذه الحالة ، ستصبح حالة النظام هي نفسها ، أي أنه لا ينبغي أن تؤدي سلسلة من نفس الحالة ، على سبيل المثال ، عمليات التحديث ، إلى حالات نهائية مختلفة للنظام.
المصدر: www.habr.com