مشاركة عبر

تصميم تطبيقات مرنة باستخدام مجموعات SDK لـ Azure Cosmos DB

  • مقالة

ينطبق على: NoSQL

عند إنشاء تطبيقات العميل التي تتفاعل مع Azure Cosmos DB من خلال أي من مجموعات SDK، من المهم فهم بعض الأساسيات الرئيسية. هذه المقالة هي دليل تصميم لمساعدتك على فهم هذه الأساسيات وتصميم تطبيقات مرنة.

نظرة عامة

للحصول على نظرة عامة في شكل الفيديو للمفاهيم التي تمت مناقشتها في هذه المقالة، راجع:

أوضاع الاتصال

يمكن لمجموعات SDK لـ Azure Cosmos DB الاتصال بالخدمة في وضعي اتصال. يمكن لمجموعات .NET وJava SDK الاتصال بالخدمة في كل من وضع البوابة والوضع المباشر، بينما يمكن للآخرين الاتصال فقط في وضع البوابة. يستخدم وضع البوابة بروتوكول HTTP ويستخدم الوضع المباشر عادة بروتوكول TCP.

يُستخدم وضع البوابة دائمًا لإحضار بيانات التعريف مثل معلومات الحساب والحاوية والتوجيه بغض النظر عن الوضع الذي تم تكوين SDK لاستخدامه. يتم تخزين هذه المعلومات مؤقتًا في الذاكرة ويتم استخدامها للاتصال بالنسخ المتماثلة للخدمة.

باختصار، بالنسبة لمجموعات SDK في وضع البوابة، يمكنك توقع نسبة استخدام الشبكة HTTP، بينما بالنسبة لمجموعات SDK في الوضع المباشر، يمكنك توقع مجموعة من نسبة استخدام الشبكتين HTTP وTCP في ظل ظروف مختلفة (مثل التهيئة أو إحضار بيانات التعريف أو معلومات التوجيه).

مثيلات العميل واتصالاته

بغض النظر عن وضع الاتصال، من الضروري الحفاظ على مثيل Singleton لعميل SDK لكل حساب لكل تطبيق. يتم تحديد نطاق الاتصالات، سواء HTTP أو TCP، إلى مثيل العميل. معظم بيئات الحساب لها قيود من حيث عدد الاتصالات التي يمكن فتحها في نفس الوقت وعندما يتم الوصول إلى هذه الحدود، سيتأثر الاتصال.

التطبيقات والشبكات الموزعة

عند تصميم التطبيقات الموزعة، هناك ثلاثة مكونات رئيسية:

  • تطبيقك والبيئة التي يعمل فيها.
  • الشبكة، التي تتضمن أي مكون بين التطبيق الخاص بك ونقطة نهاية خدمة Azure Cosmos DB.
  • نقطة نهاية خدمة Azure Cosmos DB.

عندما تحدث حالات فشل، فإنها غالبًا ما تقع في أحد هذه المجالات الثلاثة، ومن المهم أن نفهم أنه نظرًا للطبيعة الموزعة للنظام، فمن غير العملي توقع توفر 100٪ لأي من هذه المكونات.

يحتوي Azure Cosmos DB على مجموعة شاملة من اتفاقيات مستوى الخدمة للتوفر، ولكن لا شيء منها بنسبة 100٪. يمكن أن تواجه مكونات الشبكة التي تربط التطبيق بنقطة نهاية الخدمة مشكلات عابرة في الأجهزة وتفقد حزم البيانات. حتى بيئة الحوسبة حيث يتم تشغيل التطبيق الخاص بك يمكن أن يكون لها ارتفاع حاد في CPU مما يؤثر على العمليات. يمكن أن تؤثر ظروف الفشل هذه على عمليات مجموعات SDK وتظهر عادة كأخطاء مع تعليمات برمجية معينة.

يجب أن يكون تطبيقك مرنًا أمام درجة معينة من العمليات الفاشلة المحتملة عبر هذه المكونات من خلال تنفيذ نُهج إعادة محاولة المعالجة على الاستجابات التي توفرها مجموعات SDK.

هل يجب على التطبيق الخاص بي إعادة محاولة المعالجة عند وجود أخطاء؟

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

التعليمة البرمجية للحالة يجب إضافة إعادة محاولة المعالجة إعادة محاولة وحدات SDK الوصف
400 لا لا طلب غير صالح
401 لا لا غير مصرح به
403 ‏‏اختياري لا محظور
404 لا لا لم يتم العثور على المورد
408 نعم نعم انتهت مهلة الطلب
409 لا لا يحدث فشل التعارض عندما يتم أخذ الهوية (المعرف ومفتاح القسم) المقدم لمورد في عملية الكتابة بواسطة مورد موجود أو عند انتهاك قيد مفتاح فريد.
410 نعم نعم الاستثناءات التي تم تجاوزها (فشل عابر لا ينبغي أن ينتهك اتفاقية مستوى الخدمة)
412 لا لا فشل الشرط المسبق هو المكان الذي تحدد فيه العملية علامة eTag تختلف عن الإصدار المتاح على الخادم. إنه خطأ تزامن أمثل. أعد محاولة الطلب بعد قراءة أحدث إصدار من المورد وتحديث eTag عند الطلب.
413 لا لا كيان الطلب كبير جداً
429 نعم نعم من الآمن إعادة محاولة المعالجة على 429. راجع الدليل لاستكشاف أخطاء HTTP 429 وإصلاحها.
449 نعم نعم خطأ عابر يحدث فقط في عمليات الكتابة، ويمكن إعادة المحاولة بأمان. يمكن أن يشير هذا إلى مشكلة في التصميم حيث يحاول عدد كبير جدا من العمليات المتزامنة تحديث نفس الكائن في Azure Cosmos DB.
500 لا لا فشلت العملية بسبب خطأ خدمة غير متوقع. اتصل بالدعم عن طريق تقديم مشكلة دعم Azure.
503 نعم نعم الخدمة غير متوفرة

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

HTTP 403

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

HTTP 429

ستعيد مجموعات SDK لـ Azure Cosmos DB محاولة معالجة أخطاء HTTP 429 افتراضيًا باتباع تكوين العميل وتكريم عنوان استجابة الخدمةx-ms-retry-after-ms، عن طريق انتظار الوقت المحدد وإعادة المحاولة بعد ذلك.

عند تجاوز عمليات إعادة محاولة المعالجة لمجموعات SDK، يتم إرجاع الخطأ إلى التطبيق الخاص بك. من الناحية المثالية، يمكن استخدام فحص العنوان x-ms-retry-after-ms في الاستجابة كتلميح لتحديد المدة التي يجب انتظارها قبل إعادة محاولة معالجة الطلب. بديل آخر هو خوارزمية التراجع الأسي أو تكوين العميل لتوسيع عمليات إعادة محاولة المعالجة على HTTP 429.

HTTP 449

ستعيد مجموعات SDK لـ Azure Cosmos DB محاولة المعالجة على HTTP 449 بتراجع تدريجي خلال فترة زمنية محددة لاستيعاب معظم السيناريوهات.

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

تعد مهلات الشبكة وحالات الفشل المتعلقة بالاتصال من بين الأخطاء الأكثر شيوعًا. تعد حزم مجموعات SDK لـ Azure Cosmos DB نفسها مرنة وستعيد محاولة معالجة مشكلات المهلات والاتصال عبر بروتوكولات HTTP وTCP إذا كانت إعادة المحاولة ممكنة:

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

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

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

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

تفاصيل التنفيذ للغة محددة

لمزيد من تفاصيل حول التنفيذ فيما يتعلق باللغة، راجع:

هل تؤثر عمليات إعادة محاولة المعالجة على زمن الانتقال الخاص بي؟

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

توفر مجموعات SDK لـ Azure Cosmos DB معلومات مفصلة في سجلاتها وتشخيصاتها التي يمكن أن تساعد في تحديد عمليات إعادة محاولة المعالجة التي تحدث. لمزيد من المعلومات، راجع كيفية تجميع تشخيصات .NET SDKوكيفية جمع تشخيصات Java SDK.

ماذا عن الانقطاعات الإقليمية؟

تغطي مجموعات SDK لـ Azure Cosmos DB التوافر الإقليمي ويمكنها إجراء عمليات إعادة محاولة المعالجة على مناطق حساب أخرى. ارجع إلى مقالة سيناريوهات وتكوينات إعادة محاولة معالجة البيئات متعددة المناطق لفهم السيناريوهات التي تتضمن مناطق أخرى.

متى تتصل بدعم العملاء

قبل الاتصال بدعم العملاء، اتبع الخطوات التالية:

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

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

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