موازنة تحميل القسم عبر مثيلات متعددة من التطبيق الخاص بك
لتوسيع نطاق تطبيق معالجة الأحداث، يمكنك تشغيل مثيلات متعددة من التطبيق وموازنة التحميل فيما بينها. في الإصدارات القديمة والمهملة، EventProcessorHost يسمح لك بموازنة التحميل بين مثيلات متعددة من البرنامج وأحداث نقطة التحقق عند تلقي الأحداث. في الإصدارات الأحدث (5.0 فصاعداً)، EventProcessorClient (.NET وJava)، أو EventHubConsumerClient (Python وJavaScript) يسمح لك أن تفعل الشيء نفسه. يتم إجراء نموذج التطوير أبسط باستخدام الأحداث. يمكنك الاشتراك في الأحداث التي تهتم بها عن طريق تسجيل معالج أحداث. إذا كنت تستخدم الإصدار القديم من مكتبة العميل، فراجع أدلة الترحيل التالية: .NET،وJava، وPython، وJavaScript.
توضح هذه المقالة سيناريو نموذجي لاستخدام مثيلات متعددة من تطبيقات العميل لقراءة الأحداث من مركز أحداث. كما يوفر لك تفاصيل حول ميزات عميل معالج الأحداث، والذي يسمح لك بتلقي الأحداث من أقسام متعددة في وقت واحد وموازنة التحميل مع المستهلكين الآخرين الذين يستخدمون نفس مركز الحدث ومجموعة المستهلكين.
إشعار
المفتاح لتوسيع نطاق لمراكز الأحداث هو فكرة تقسيم المستهلكين. وعلى النقيض من نمط المستهلكين المتنافسين، فإن نمط المستهلك المقسم يمكن من تحقيق نطاق عالٍ عن طريق إزالة التكدس وتيسير إنهاء التوازي.
سيناريو مثال
على سبيل المثال، فكر في شركة أمن منزلي تراقب 100,000 منزل. كل دقيقة، فإنه يحصل على البيانات من أجهزة الاستشعار المختلفة مثل كاشف الحركة، الباب / نافذة استشعار مفتوحة، كاشف كسر الزجاج، وهلم جرا، مثبتة في كل منزل. توفر الشركة موقعاً على شبكة الإنترنت للمقيمين لمراقبة نشاط منازلهم في الوقت الحقيقي تقريباً.
يدفع كل مستشعر البيانات إلى مركز الحدث. تم تكوين لوحة وصل الحدث مع 16 قسماً. في نهاية الاستهلاك تحتاج إلى آلية يمكنها قراءة هذه الأحداث، ودمجها (التصفية، والتجميع، وما إلى ذلك) وتفريغ التجميع إلى نقطة تخزين، والتي يتم إسقاطها بعد ذلك إلى صفحة ويب سهلة الاستخدام.
تطبيق المستهلك
عند تصميم مستهلك في بيئة موزعة، يجب أن يعالج السيناريو المتطلبات التالية:
- المقياس: إنشاء عدة مستهلكين، مع كل مستهلك أخذ ملكية القراءة من أقسام مراكز الأحداث قليلة.
- موازنة التحميل: زيادة أو تقليل المستهلكين بشكل حيوي. على سبيل المثال، عندما يتم إضافة نوع مستشعر جديد (على سبيل المثال، كاشف أول أكسيد الكربون) إلى كل منزل، يزداد عدد الأحداث. في هذه الحالة، المشغل (الإنسان) يزيد عدد حالات المستهلك. بعد ذلك، يمكن إعادة توازن مجموعة من المستهلكين عدد الأقسام التي يمتلكونها، لمشاركة الحمل مع المستهلكين المضافين حديثاً.
- سيرة ذاتية سلسة على الفشل: إذا فشل المستهلك(المستهلك أ)(على سبيل المثال، تعطل الجهاز الظاهري الذي يستضيف المستهلك فجأة)، فيمكن للمستهلكين الآخرين التقاط الأقسام التي يملكها المستهلك أ والاستمرار. أيضاً، يجب أن تكون نقطة المتابعة، التي تسمى نقطة تفتيش أو إزاحة،عند النقطة المحددة التي فشل فيها المستهلك أ، أو قبل ذلك بقليل.
- استهلاك الأحداث: بينما تتعامل النقاط الثلاث السابقة مع إدارة المستهلك، يجب أن تكون هناك تعليمات برمجية لاستهلاك الأحداث والقيام بشيء مفيد معها. على سبيل المثال، تجميعه وتحميله إلى تخزين الكائن الثنائي كبير الحجم.
معالج الأحداث أو عميل المستهلك
لا تحتاج إلى بناء الحل الخاص بك لتلبية هذه المتطلبات. توفر مراكز الأحداث لـ SDKs هذه الوظيفة. في .NET أو Java SDKs، يمكنك استخدام عميل معالج حدث (EventProcessorClient)، وفي Python وJavaScript SDKs، يمكنك استخدام EventHubConsumerClient. في الإصدار القديم من SDK، كان مضيف معالج الأحداث (EventProcessorHost) هو الذي يدعم هذه الميزات.
بالنسبة لمعظم سيناريوهات الإنتاج، نوصي باستخدام عميل معالج الأحداث لقراءة الأحداث ومعالجتها. يهدف عميل المعالج إلى توفير تجربة قوية لمعالجة الأحداث عبر جميع أقسام مركز الأحداث بأسلوب يتسم بالأداء والتسامح مع الخطأ مع توفير وسيلة للتحقق من تقدمه. يمكن لعملاء معالج الأحداث العمل بشكل تعاوني ضمن سياق مجموعة مستهلكة لمركز حدث معين. سيقوم العملاء تلقائياً بإدارة توزيع العمل وموازنة عندما تصبح المثيلات متوفرة أو غير متوفرة للمجموعة.
ملكية القسم
عادةً ما يمتلك مثيل معالج الأحداث ويعالجها من قسم واحد أو أكثر. يتم توزيع ملكية الأقسام بالتساوي بين جميع مثيلات معالج الأحداث النشطة المقترنة بمركز حدث ومجموعة مجموعات المستهلكين.
يتم إعطاء كل معالج حدث معرف فريد ومطالبات ملكية أقسام بإضافة أو تحديث إدخال في مخزن نقطة تفتيش. تتواصل جميع مثيلات معالج الأحداث مع هذا المتجر بشكل دوري لتحديث حالة المعالجة الخاصة بها وللتعرف على المثيلات النشطة الأخرى. ثم يتم استخدام هذه البيانات لموازنة التحميل بين المعالجات النشطة. يمكن للمثيلات الجديدة الانضمام إلى تجمع المعالجة لتوسيع نطاقه. عندما تنخفض المثيلات، إما بسبب الفشل أو التحجيم، يتم نقل ملكية القسم بأمان إلى معالجات نشطة أخرى.
تتبع سجلات ملكية الأقسام في مخزن نقاط الفحص بتتبع مساحة اسم مراكز الأحداث واسم مركز الحدث ومجموعة المستهلك ومعرف معالج الحدث (المعروف أيضاً باسم المالك) ومعرف القسم ووقت آخر تعديل.
| مساحة اسم "مراكز الأحداث" | اسم Event Hub | مجموعة المستهلكين | المالك | معرف القسم | تاريخ آخر تعديل |
|---|---|---|---|---|---|
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 3be3f9d3-9d9e-4c50-9491-85ece8334ff6 | 0 | 2020-01-15T01:22:15 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | f5cc5176-ce96-4bb4-bbaa-a0e3a9054ecf | 1 | 2020-01-15T01:22:17 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 72b980e9-2efc-4ca7-ab1b-ffd7bece8472 | 2 | 2020-01-15T01:22:10 |
| : | |||||
| : | |||||
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 844bd8fb-1f3a-4580-984d-6324f9e208af | 15 | 2020-01-15T01:22:00 |
يكتسب كل مثيل معالج حدث ملكية قسم ويبدأ في معالجة القسم من آخر نقطة فحص معروفة. إذا فشل معالج (إيقاف تشغيل VM)، ثم اكتشاف مثيلات أخرى عن طريق النظر في آخر وقت معدل. تحاول مثيلات أخرى الحصول على ملكية الأقسام المملوكة مسبقا من قبل المثيل غير النشط. يضمن مخزن نقاط التحقق نجاح مثيل واحد فقط في المطالبة بملكية قسم. لذلك، في أي نقطة معينة من الزمن، هناك على الأكثر معالج واحد يتلقى الأحداث من القسم.
تلقي الرسائل
عند إنشاء معالج حدث، يمكنك تحديد الوظائف التي تعالج الأحداث والأخطاء. كل استدعاء إلى الدالة التي تعالج الأحداث يسلم حدث واحد من قسم معين. إنها مسؤوليتكم للتعامل مع هذا الحدث. إذا كنت تريد التأكد من أن المستهلك يعالج كل رسالة مرة واحدة على الأقل، تحتاج إلى كتابة الرمز الخاص بك مع منطق إعادة المحاولة. ولكن كن حذراً بشأن الرسائل غير القابلة للمعالجة.
نوصي بأن تفعل الأشياء بسرعة نسبياً. وهذا هو، القيام بأقل قدر ممكن من المعالجة. إذا كنت بحاجة إلى الكتابة إلى التخزين والقيام ببعض التوجيه، فمن الأفضل استخدام مجموعتين من المستهلكين واثنين من معالجات الأحداث.
نقطة التحقق
نقطة التحقق هي عملية يقوم معالج الأحداث من خلالها بوضع علامة على موضع آخر حدث تمت معالجته بنجاح أو الالتزام به داخل قسم. يتم وضع علامة نقطة اختبار عادة ضمن الدالة التي تعالج الأحداث ويحدث على أساس لكل قسم داخل مجموعة المستهلكين.
إذا قطع معالج حدث من قسم، يمكن استئناف مثيل آخر معالجة القسم عند نقطة التحقق التي تم تنفيذها مسبقاً من قبل المعالج الأخير من هذا القسم في تلك المجموعة الاستهلاكية. عند اتصال المعالج، فإنه يمرر الإزاحة إلى لوحة وصل الحدث لتحديد الموقع الذي يجب بدء القراءة فيه. وبهذه الطريقة، يمكنك استخدام نقطة اختبار لوضع علامة على الأحداث على أنها "كاملة" بواسطة التطبيقات للمتلقين للمعلومات ولتوفير المرونة عند إيقاف معالج الأحداث. من الممكن العودة إلى البيانات القديمة عن طريق تحديد إزاحة أقل من عملية نقاط التفتيش هذه.
عند تنفيذ نقطة التحقق لوضع علامة حدث كما تمت معالجتها، تتم إضافة إدخال في مخزن نقطة فحص أو تحديث مع حدث الإزاحة ورقم التسلسل. يجب على المستخدمين تحديد تكرار تحديث نقطة الفحص. يمكن أن يؤثر التحديث بعد كل حدث تمت معالجته بنجاح في الأداء والتكلفة حيث يؤدي إلى بدء عملية الكتابة إلى مخزن نقاط الفحص الأساسي. أيضاً، نقطة فحص كل حدث واحد يدل على نمط المراسلة في قائمة الانتظار التي قد يكون قائمة انتظار "ناقل الخدمة" خياراً أفضل من مركز الحدث. الفكرة وراء مراكز الأحداث هي أن تحصل على تسليم "مرة واحدة على الأقل" على نطاق واسع. من خلال جعل أنظمة المصب الخاصة بك معطلة، من السهل التعافي من حالات الفشل أو إعادة التشغيل التي تؤدي إلى تلقي نفس الأحداث عدة مرات.
اتبع هذه التوصيات عند استخدام Azure Blob Storage كمخزن نقطة تحقق:
- استخدم حاوية منفصلة لكل مجموعة مستهلكين. يمكنك استخدام نفس حساب التخزين، ولكن استخدام حاوية واحدة لكل مجموعة.
- لا تستخدم الحاوية لأي شيء آخر، ولا تستخدم حساب التخزين لأي شيء آخر.
- يجب أن يكون حساب التخزين في نفس المنطقة التي يوجد فيها التطبيق المنشور. إذا كان التطبيق محليا، فحاول اختيار أقرب منطقة ممكنة.
في صفحة Storage account في مدخل Microsoft Azure، في قسم Blob service ، تأكد من تعطيل الإعدادات التالية.
- مساحة الاسم الهرمية
- حذف مبدئي لكائن ثنائي كبير الحجم
- تعيين الإصدار
أمان مؤشر الترابط ومثيلات المعالج
بشكل افتراضي، يتم استدعاء الدالة التي تعالج الأحداث بشكل تسلسلي لقسم معين. الأحداث اللاحقة والمكالمات إلى هذه الوظيفة من نفس قائمة انتظار القسم حتى وراء الكواليس كما مضخة الحدث يستمر في تشغيل في الخلفية على المواضيع الأخرى. يمكن معالجة الأحداث من أقسام مختلفة بشكل متزامن وأي حالة مشتركة يتم الوصول إليها عبر الأقسام يجب أن تتم مزامنتها.
المحتوى ذو الصلة
راجع البدايات السريعة التالية: