الميزات والمصطلحات في مراكز أحداث Azure

  • مقالة

مراكز أحداث Azure هي خدمة معالجة أحداث قابلة للتطوير تستوعب قدرًا كبيرًا من الأحداث والبيانات وتعالجه، وذلك بزمن انتقال قصير وموثوقية عالية. للحصول على نظرة عامة عالية المستوى على الخدمة، راجع ما هي مراكز الأحداث؟.

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

مساحة الاسم

مساحة اسم "مركز الأحداث" هي حاوية إدارة لمراكز الأحداث (أو الموضوعات، بلغة Kafka). وتوفر نقاط نهاية الشبكة المتكاملة مع DNS ومجموعة من التحكم في الوصول وميزات إدارة تكامل الشبكة مثل تصفية IPونقطة نهاية خدمة الشبكة الظاهرية ورابط خاص.

Image showing an Event Hubs namespace

الأقسام

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

Image that shows an event hub with a few partitions.

يمكن اعتبار القسم كسجل تثبيت. تحتوي الأقسام على بيانات الحدث التي تحتوي على المعلومات التالية:

  • نص الحدث
  • حقيبة خصائص معرفة من قبل المستخدم تصف الحدث
  • بيانات التعريف مثل إزاحتها في القسم، رقمها في تسلسل الدفق
  • الطابع الزمني من جانب الخدمة الذي تم قبوله فيه

Diagram that displays the older to newer sequence of events.

مزايا استخدام الأقسام

تم تصميم مراكز الأحداث للمساعدة في معالجة كميات كبيرة من الأحداث، ويساعد التقسيم في ذلك بطريقتين:

  • على الرغم من أن Event Hubs هي خدمة PaaS، هناك حقيقة مادية أسفلها. يتطلب الحفاظ على سجل يحافظ على ترتيب الأحداث أن يتم الاحتفاظ بهذه الأحداث معا في التخزين الأساسي والنسخ المتماثلة الخاصة به، مما يؤدي إلى سقف معدل النقل لمثل هذا السجل. يسمح التقسيم باستخدام سجلات متوازية متعددة لنفس مركز الحدث وبالتالي ضرب سعة معدل نقل الإدخال والإخراج الخام (IO) المتوفرة.
  • يجب أن تكون التطبيقات الخاصة بك قادرة على مواكبة معالجة حجم الأحداث التي يتم إرسالها إلى مركز الحدث. قد يكون معقدا ويتطلب قدرة معالجة كبيرة ومتدرجة ومتوازية. سعة عملية واحدة لمعالجة الأحداث محدودة، لذلك تحتاج إلى عدة عمليات. الأقسام هي الطريقة التي يغذي بها حلك هذه العمليات ومع ذلك يضمن أن كل حدث لديه مالك معالجة واضح.

عدد الأقسام

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

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

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

لا يهم عدد الأقسام الموجودة في مركز الحدث عندما يتعلق الأمر بالتسعير. يعتمد ذلك على عدد وحدات التسعير (وحدات الإنتاجية (TUs) للمستوى القياسي، ووحدات المعالجة (PUs) للمستوى المتميز، وووحدات السعة (CUs) للمستوى المخصص) لمساحة الاسم أو المجموعة المخصصة. على سبيل المثال، يتحمل مركز أحداث المستوى القياسي الذي يحتوي على 32 قسما أو مع قسم واحد نفس التكلفة بالضبط عند تعيين مساحة الاسم إلى سعة TU واحدة. أيضًا، يمكنك مقياس وحدات TUs أو وحدات PUs في مساحة الاسم أو وحدات CUs لمجموعة مخصصة لديك مستقلة عن عدد الأقسام.

نظرا لأن القسم هو آلية لتنظيم البيانات تسمح لك بنشر البيانات واستهلاكها بطريقة متوازية. نوصي بموازنة وحدات التحجيم (وحدات معدل النقل للمستوى القياسي، أو وحدات المعالجة للطبقة المتميزة، أو وحدات السعة للطبقة المخصصة) والأقسام لتحقيق المقياس الأمثل. بشكل عام، نوصي بحد أقصى لمعدل نقل 1 ميغابايت/ثانية لكل قسم. لذلك، فإن قاعدة الإبهام لحساب عدد الأقسام هي تقسيم الحد الأقصى لمعدل النقل المتوقع على 1 ميغابايت/ثانية. على سبيل المثال، إذا كانت حالة الاستخدام الخاصة بك تتطلب 20 ميغابايت/ثانية، نوصي باختيار 20 قسما على الأقل لتحقيق معدل النقل الأمثل.

ومع ذلك، إذا كان لديك نموذج يكون فيه التطبيق الخاص بك ترابطا إلى قسم معين، فإن زيادة عدد الأقسام ليست مفيدة. لمزيد من المعلومات، راجع availability and consistency

تعيين الأحداث إلى أقسام

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

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

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

إشعار

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

ناشرو الأحداث

أي كيان يرسل البيانات إلى مركز أحداث يعد ناشر حدث (يستخدم ترادفيًا مع المصطلح منتج الحدث). يمكن لناشري الأحداث نشر الأحداث باستخدام HTTPS أو AMQP 1.0 أو بروتوكول Kafka. يستخدم ناشري الأحداث التخويل المستند إلى معرف Microsoft Entra مع رموز JWT المميزة الصادرة عن OAuth2 أو رمز توقيع الوصول المشترك الخاص بمركز الأحداث (SAS) للوصول إلى النشر.

يمكنك نشر حدث عبر AMQP 1.0 أو بروتوكول Kafka أو HTTPS. توفر خدمة مراكز الأحداث REST APIو.NETوJavaوPythonوJavaScript ومكتبات عملاء Go لنشر الأحداث إلى مركز أحداث. فيما يتعلق بأوقات التشغيل والأنظمة الأساسية الأخرى، يمكنك استخدام أي عميل AMQP 1.0، مثل Apache Qpid.

اختيار استخدام AMQP أو HTTPS محددة لسيناريو الاستخدام. يتطلب AMQP إنشاء مأخذ توصيل ثنائي الاتجاه مستمر بالإضافة إلى أمان مستوى النقل (TLS) أو SSL/TLS. AMQP لديه تكاليف شبكة أعلى عند تهيئة الجلسة، ولكن HTTPS يتطلب حمل TLS إضافي لكل طلب. يتمتع AMQP بأداء أعلى للناشرين المتكررين ويمكنه تحقيق زمن انتقال أقل بكثير عند استخدامه مع تعليمات النشر البرمجية غير المتزامنة.

يمكنك نشر الأحداث بشكل فردي أو على دفعات. للمنشور الواحد حد يبلغ 1 ميجابايت، بصرف النظر عما إذا كان حدثًا واحدًا أو دفعةً. يتم رفض نشر الأحداث الأكبر من هذا الحد.

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

Diagram that shows how partition keys are mapped to partitions in an event hub.

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

استبقاء بالحدث

تتم إزالة الأحداث المنشورة من مركز أحداث استنادًا إلى سياسة استبقاء قابلة للتكوين وقائمة على الوقت المناسب. فيما يلي بعض النقاط المهمة:

  • القيمة الافتراضية وأقصر فترة استبقاء ممكنة هي ساعة واحدة. حاليا، يمكنك تعيين فترة الاستبقاء بالساعات فقط في مدخل Microsoft Azure. يسمح قالب Resource Manager وPowerShell وCLI بتعيين هذه الخاصية بالأيام فقط.
  • فيما يخص معيار مراكز الأحداث، يكون الحد الأقصى لفترة الاستبقاء 7 أيام.
  • بالنسبة إلى Event Hubs Premium وDedicated، فإن الحد الأقصى لفترة الاستبقاء هو 90 يوماً.
  • وإذا غيرت فترة الاستبقاء، فإنها تنطبق على جميع الأحداث، بما في ذلك الأحداث الموجودة بالفعل في مركز الأحداث.

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

وإذا كنت بحاجة إلى أرشفة الأحداث بعد فترة الاستبقاء المسموح بها، يمكنك تخزينها تلقائيًا في Azure Storage أو Azure Data Lake عن طريق تشغيل ميزة التقاط مراكز الأحداث. أما إذا كنت بحاجة إلى البحث عن تلك المحفوظات العميقة أو تحليلها، فيمكنك استيرادها بسهولة إلى Azure Synapse أو متاجر ومنصات تحليلات أخرى مماثلة.

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

إشعار

فمراكز الأحداث هي مشغل دفق أحداث في الوقت الحقيقي وليست مصممة لتُستخدم بدلاً من قاعدة بيانات و/أو كمخزن دائم لتدفقات الأحداث المحفوظة بشكل لا نهائي.

وكلما كان تاريخ دفق الأحداث أعمق، احتجت إلى فهارس مساعدة للعثور على شريحة تاريخية معينة من دفق معين. لا يقع فحص حمولات الأحداث والفهرسة ضمن نطاق ميزات مراكز الأحداث (أو Apache Kafka). ومن ثمَّ، تعد مستودعات ومحركات قواعد البيانات والتحليلات المتخصصة مثل متجر Azure Data Lake وتحليلات Azure Data Lake وAzure Synapse أكثر ملاءمة لتخزين الأحداث التاريخية.

التقاط مراكز الأحداث يتكامل مباشرةً مع تخزين Azure Blob ومستودع البيانات Data Lake Storage، ومن خلال هذا التكامل، يتم أيضًا تمكين الأحداث المتدفقة مباشرةً إلى Azure Synapse.

سياسة الناشر

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

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

لا يتعين عليك إنشاء أسماء ناشرين مسبقًا، ولكن يجب أن تتطابق مع الرمز المميز SAS المستخدم عند نشر حدث، وذلك لضمان هويات ناشر مستقلة. عند استخدام نُهج الناشر، يجب تعيين قيمة PartitionKey إلى اسم الناشر. ويجب أن تتطابق هذه القيم للعمل بشكل صحيح.

التسجيل

يمكنك التقاط مراكز الأحداث من التقاط البيانات المتدفقة تلقائيًا في مراكز الأحداث وحفظها حسب اختيارك إما إلى حساب تخزين Blob أو حساب تخزين مستودع البيانات Azure (Azure Data Lake Storage). ويمكنك تمكين الالتقاط من بوابة Azure، وتحديد حد أدنى للحجم والوقت لتنفيذ عملية الالتقاط. وتحدد باستخدام التقاط مراكز الأحداث حساب تخزين Azure Blob الخاص بك والحاوية أو حساب Azure Data Lake Storage الذي يُستخدم لتخزين البيانات التي تم التقاطها. وتُكتَب البيانات التي تم التقاطها بتنسيق Apache Avro.

Diagram that shows the capturing of Event Hubs data into Azure Storage or Azure Data Lake Storage.

للملفات التي تم إنتاجها بواسطة التقاط مراكز الأحداث مخطط Avro التالي:

Diagram showing the structure of captured Avro data.

إشعار

يمكنك التقاط البيانات المتدفقة في مراكز الأحداث في حساب Azure Data Lake Storage Gen2 بتنسيق Parquet، عند عدم استخدام محرر التعليمات البرمجية في مدخل Microsoft Azure. لمزيد من المعلومات، راجع كيفية: التقاط البيانات من مراكز الأحداث بتنسيق Parquet والبرنامج التعليمي: التقاط بيانات مراكز الأحداث بتنسيق Parquet وتحليلها باستخدام Azure Synapse Analytics.

رموز SAS المميزة

تستخدم مراكز الأحداث توقيعات الوصول المشترك المتوفرة على مستوى مساحة الاسم ومركز الأحداث. ويتم إنشاء رمز SAS المميز من مفتاح SAS وهو تجزئة SHA لعنوان URL، مرمز بتنسيق محدد. يمكن لـ "مراكز الأحداث" إعادة إنشاء التجزئة باستخدام اسم المفتاح (النهج) والرمز المميز ومن ثمَّ مصادقة المرسل. وعادة ما يتم إنشاء رموز SAS المميزة لناشري الأحداث مع امتيازات الإرسال فقط على مركز أحداث معينة. وتعد آلية عنوان URL لرمز SAS المميز أساس تعريف الناشر المقدم في سياسة الناشر. لمزيد من المعلومات حول العمل بـ SAS، راجع مصادقة توقيع الوصول المشترك بناقل الخدمة.

مستهلكو الأحداث

أي كيان يقرأ بيانات الحدث من مركز أحداث هو مستهلك حدث. ويتصل جميع مستهلكي مراكز الأحداث عبر جلسة AMQP 1.0 ويتم تسليم الأحداث خلال الجلسة عند توفرها. لا يحتاج العميل إلى الاستقصاء عن توفر البيانات.

مجموعات المستهلكين

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

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

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

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

تظهر الأمثلة التالية اتفاقية URI لمجموعة المستهلكين:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

يوضح الشكل التالي بنية معالجة دفق مراكز الأحداث:

Diagram that shows the Event Hubs stream processing architecture.

إزاحات الدفق

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

Diagram that shows a partition with an offset.

التحقق

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

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

هام

يتم توفير الإزاحات من خلال خدمة مراكز الأحداث. إن فحص نقطة التفتيش في أثناء معالجة الأحداث مسؤولية المستهلك.

اتبع هذه التوصيات عند استخدام Azure Blob Storage كمخزن نقطة تحقق:

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

في صفحة Storage account في مدخل Microsoft Azure، في قسم Blob service ، تأكد من تعطيل الإعدادات التالية.

  • مساحة الاسم الهرمية
  • حذف مبدئي لكائن ثنائي كبير الحجم
  • تعيين الإصدار

ضغط السجل

تدعم Azure Event Hubs ضغط سجل الأحداث للاحتفاظ بأحدث الأحداث لمفتاح حدث معين. باستخدام موضوع مراكز الأحداث/Kafka المضغوط، يمكنك استخدام الاستبقاء المستند إلى المفتاح بدلا من استخدام الاستبقاء المستند إلى الوقت الخشن.

لمزيد من المعلومات حول ضغط السجل، راجع ضغط السجل.

المهام الاستهلاكية الشائعة

يتصل جميع مستهلكي Event Hubs عبر جلسة AMQP 1.0، وهي قناة اتصال ثنائية الاتجاه مراعية للحالة. يحتوي كل قسم على جلسة AMQP 1.0 تسهل نقل الأحداث التي يتم فصلها حسب القسم.

الاتصال بقسم

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

قراءة الأحداث

بعد فتح جلسة عمل AMQP 1.0 والارتباط لقسم معين، يتم تسليم الأحداث إلى العميل AMQP 1.0 من خلال خدمة "مراكز الأحداث". تتيح آلية التسليم هذه معدل نقل أعلى وسرعة وصول أقل من الآليات المستندة إلى السحب مثل HTTP GET. كما يتم إرسال الأحداث إلى العميل، كل مثيل بيانات أحداث يحتوي على بيانات التعريف الهامة مثل الإزاحة ورقم التسلسل التي يتم استخدامها لتسهيل التفتيش لتسلسل الحدث.

بيانات الحدث:

  • الإزاحة
  • الرقم التسلسلي
  • النص الأساسي
  • خصائص المستخدم
  • خصائص النظام

تقع على عاتقك مسؤولية إدارة الإزاحة.

مجموعات التطبيقات

مجموعة التطبيقات هي مجموعة من تطبيقات العميل التي تتصل بمساحة اسم مراكز الأحداث التي تشترك في شرط تعريف فريد مثل سياق الأمان - نهج الوصول المشترك أو معرف تطبيق Microsoft Entra.

تمكّنك خدمة مراكز الأحداث من Azure من تحديد نُهج الوصول إلى الموارد مثل نُهج التقييد لمجموعة تطبيق معينة ويتحكم في تدفق الأحداث (النشر أو الاستهلاك) بين تطبيقات العميل ومراكز الأحداث.

لمزيد من المعلومات، راجع Resource governance for client applications with application groups.

دعم Apache Kafka

يوفر دعم البروتوكول لعملاء Apache Kafka (الإصدارات >=1.0) نقاط نهاية تمكن تطبيقات Kafka الموجودة من استخدام مراكز الأحداث. يمكن ببساطة إعادة تكوين معظم تطبيقات Kafka الحالية للإشارة إلى مساحة اسم s بدلا من خادم نظام مجموعة Kafka bootstrap.

من منظور التكلفة والجهد التشغيلي والموثوقية، تعد مراكز الأحداث Azure بديلاً رائعًا لنشر وتشغيل أنظمة المجموعات Kafka وZookeeper الخاصة بك وعروض Kafka كخدمة غير الأصلية في Azure.

بالإضافة إلى الحصول على نفس الوظائف الأساسية مثل وسيط Apache Kafka، يمكنك أيضا الوصول إلى ميزات Azure Event Hubs مثل الدفعات التلقائية والأرشفة عبر التقاط مراكز الأحداث، والتحجيم التلقائي والموازنة، والتعافي من الكوارث، ودعم منطقة التوفر المحايدة من حيث التكلفة، وتكامل الشبكة المرن والآمن، ودعم البروتوكولات المتعددة بما في ذلك بروتوكول AMQP-over-WebSockets الصديق لجدار الحماية.

الخطوات التالية

لمزيد من المعلومات حول مراكز الأحداث، قم بزيارة الارتباطات التالية: