الحدث الجديد وإعادة إرسال الرسالة ليسا الشيء نفسه في إعداد بيانات النموذج. قد تصل الرسالة التي تصف الواقعة نفسها أكثر من مرة. لذلك نحتاج تعريفا لهوية الحدث وسياسة لدى مصدره؛ تساوي عدد الرسائل وعدد الوقائع افتراض يحتاج تحققا.
الخلاصة السريعة
عد الوقائع حسب هوية موثقة للحدث، وعد محاولات الوصول منفصلة، ولا تستنتج الهوية من تشابه المحتوى أو الوقت وحدهما.
- في المثال نفترض مصدرا ملتزما يحفظ الهوية عند إعادة الإرسال؛ ثلاث مرات وصول تمثل حدثين، لا ثلاث وقائع.
- تشترط CloudEvents1.0.2 تفرد source مع id لكل حدث مميز؛ يجوز أن تحمل إعادة إرسال نسخة المعرف نفسه. [1]
- قد يختلف وقت الوصول بين نسختين، وقد يتشابه محتوى حدثين مختلفين؛ لا يكفي أحدهما وحده لإثبات الهوية.
- افحص عقد المنتج واكتمال الحقول؛ تسمح المواصفة للمستهلك بافتراض أن source وid المتساويين يصفان نسخا، ولا تثبت التزام أي ملف عشوائي بذلك. [1]
هل كل مرة وصول واقعة جديدة؟
نفترض نظاما تعليميا يسجل وضع بطاقات في حافظة. تصل رسالة عن واقعة ذات معرف ح7، ثم تعاد رسالتها بالهوية نفسها، ثم تصل رسالة عن واقعة ح8. وبشرط أن المصدر يميز الوقائع فعلا ويحفظ الهوية عند إعادة الإرسال، يكون لدينا ثلاث مرات وصول وواقعتان.
قد نحتاج كلا العددين لسؤالين مختلفين: عدد الوقائع يصف ما حدث، وعدد محاولات الوصول يصف ما استقبله نظام التسجيل. إذا أعددنا أمثلة نموذج تتعلق بنشاط الحافظة، فاعتبار كل وصول واقعة مستقلة قد يكرر تمثيل الواقعة الأولى. هذا مثال مفترض، وليس قياسا لشبكة أو نتيجة تشغيل دفق.
لماذا نستخدم المصدر مع المعرف؟
تحدد CloudEvents1.0.2 أن يضمن المنتج تفرد الجمع بين source وid لكل حدث مميز. ويمكن لنسخة حدث يعاد إرسالها أن تحمل id نفسه. [1]
في مثالنا المصدر س1 هو نفسه في مرات الوصول الثلاث. لكن لو جاء مصدر آخر س2 بمعرف ح7، فلا ندمجه مع س1 وح7 بسبب تشابه المعرف فقط. نقرأ تعريف النطاق الذي يجعل الهوية فريدة، بدلا من افتراض أن الرقم أو النص فريد في كل المصادر.
- الجدول يفترض سياسة مصدر صحيحة لتمييز الوقائع؛ لا يثبت أن نظاما فعليا التزم بها.
| المصدر المفترض | معرف الحدث | وصول الرسالة في المثال |
|---|---|---|
| س1 | ح7 | المرة الأولى |
| س1 | ح7 | إعادة إرسال بالهوية نفسها |
| س1 | ح8 | رسالة عن واقعة أخرى |
هل الوقت أو المحتوى بديل كاف للهوية؟
قد تتأخر نسخة عن نسختها السابقة، فيختلف وقت استقبالها رغم أننا نقصد الواقعة نفسها. وفي المقابل يمكن، في المثال، وضع بطاقتين متشابهتين في وقتين مختلفين، فتتشابه الرسالتان في وصف البطاقة وهما تصفان واقعتين. نحفظ هوية الحدث منفصلة عن وصفه ووقت وصول رسالته.
وإذا لم يسجل المصدر معرفا موثوقا، لا نعلن أن تشابه الكلمات كشف كل النسخ أو كل الوقائع الجديدة. نقترح إظهار الحالات المحتملة للمراجعة، وتوثيق ما نعرفه وما لم نحسمه، قبل بناء عدد الأحداث الذي تحتاجه المهمة.
ماذا نراجع قبل اعتماد هذه القاعدة؟
تسمح المواصفة للمستهلك بأن يفترض أن الأحداث المتساوية في source وid نسخ مكررة. [1]
لكن تطبيق هذه القاعدة على ملف مفترض يحتاج فهم سياسة منتجه: كيف يمنح المعرف، وما نطاق المصدر، وكيف يعيد الإرسال؟ وجود عمود يحمل اسم id وحده لا يثبت التزامه بعقد CloudEvents أو حفظ الهوية الصحيحة.
إذا جاءت الهوية نفسها بمحتويات متعارضة، نطلب تفسيرا من المصدر ولا نختار آخر محتوى لمجرد أنه وصل لاحقا. نحتفظ بسجل الوصول ومبرر تجميع النسخ، حتى لا نفقد أثر المشكلة أثناء إعداد بيانات النموذج. هذه خطة مراجعة تعليمية؛ لم نرسل رسائل أو نختبر منتجا فعليا.
المصادر ومتابعة القراءة
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.