توقف اليوم دودو. نص غير متزامن

مرحبا يا هبر! حلمت كل من SRE في فريقنا من النوم بسلام في الليل. الأحلام تتحقق. في هذه المقالة سأتحدث عن هذا وكيف نحقق أداء واستقرار نظام Dodo IS الخاص بنا.

سلسلة من المقالات حول انهيار نظام Dodo IS * :

1. اليوم توقف دودو. النصي متزامن.
2. اليوم الذي توقف فيه دودو. نص غير متزامن.

* تمت كتابة المواد بناءً على أدائي في DotNext 2018 في موسكو .

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

نقدم مصطلح التزامن

قبل الوصول إلى المزامنة ، يجب إدخال المصطلح "التزامن".

في نظرية الاصطفاف ، Concurrency هو عدد العملاء الموجودين حاليًا داخل النظام. أحيانًا ما يتم الخلط بين التزامن والتوازي ، لكن في الواقع هذان أمران مختلفان.

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

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

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

Async / await هو السكر النحوي لـ State Machine ، وهو نموذج التزامن مفيد آخر يمكن تشغيله في بيئة ذات ترابط واحد. في جوهرها ، هذا هو تعاوني تعدد المهام - النموذج نفسه لا يأخذ التوازي في الاعتبار على الإطلاق. بالاشتراك مع Multithreading ، نحصل على نموذج واحد أعلى من الآخر ، والحياة معقدة للغاية.

مقارنة بين النموذجين

كيف نجحت في نموذج المهام المتعددة الاستباقية

لنفترض أن لدينا 20 موضوعًا و 20 طلبًا في الثانية. تظهر الصورة ذروة - 200 طلب في النظام في نفس الوقت. كيف يمكن أن يحدث هذا:

• يمكن تجميع الطلبات إذا نقر 200 عميل على زر في نفس الوقت ؛
• يستطيع جامع البيانات المهملة إيقاف الطلبات لعشرات الملي ثانية ؛
• يمكن تأخير الطلبات في أي قائمة انتظار إذا كان الوكيل يدعم قائمة الانتظار.

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

لنفترض أن خوارزمية تجمع مؤشرات الترابط الذكية (وهناك عناصر للتعلم الآلي هناك) قررت أنه حتى الآن لا يوجد سبب لزيادة عدد مؤشرات الترابط. تجمع الاتصال في MySql هو 20 أيضًا لأن مؤشرات الترابط = 20. وفقا لذلك ، نحن بحاجة فقط 20 اتصالات ل SQL.



في هذه الحالة ، يكون مستوى التزامن الخادم من وجهة نظر النظام الخارجي = 200. وقد تلقى الخادم هذه الطلبات بالفعل ، لكنه لم يستكملها بعد. ومع ذلك ، بالنسبة للتطبيق الذي يتم تشغيله في نموذج Multithreading ، فإن عدد الطلبات المتزامنة محدود بالحجم الحالي لـ Thread Pool = 20. لذلك ، نحن نتعامل مع درجة التزامن = 20.

كيف يعمل كل شيء الآن في نموذج المتزامن

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



ماذا يعني هذا بالنسبة لطلبنا؟ الصورة الخارجية هي نفسها - مستوى التزامن = 200. في الوقت نفسه ، تغير الوضع في الداخل. سابقا ، كانت الطلبات "مزدحمة" في قائمة انتظار ThreadPool ، والآن درجة التزامن للتطبيق هي أيضا 200 ، لأنه ليس لدينا قيود على جزء من TaskScheduler. الصيحة! لقد حققنا هدف التزامن - تطبيق "cope" مع أي درجة تقريبًا من التزامن!

النتائج: تدهور غير خطي للنظام

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

عند التحميل الكامل على قاعدة البيانات ، في أفضل الأحوال ، يتحلل زمن الاستجابة بشكل خطي: ​​لقد قدمت ضعف عدد الاستفسارات ، وبدأ العمل مرتين بطيئة. في الممارسة العملية ، بسبب المنافسة على الاستعلام ، ستحدث النفقات العامة بالضرورة ، وقد يتضح أن النظام سوف يتحلل بشكل غير خطي.

لماذا يحدث هذا؟

أسباب الترتيب الثاني:

• يجب الآن الاحتفاظ بقاعدة البيانات في نفس الوقت في ذاكرة بنية البيانات لخدمة المزيد من الطلبات ؛
• تحتاج قاعدة البيانات الآن إلى خدمة مجموعات أكبر (وهذا غير ملائم من الناحية الحسابية).

السبب الأول:

• خلاف ، والتي نوقشت قليلا في المادة السابقة .

في النهاية ، يكافح المتزامن الموارد المحدودة ويفوز! فشل قاعدة البيانات ويبدأ في إبطاء. من هذا ، يزيد الخادم من التزامن ، ولم يعد النظام قادرًا على الخروج من هذا الموقف بشرف.

خادم متلازمة الموت المفاجئ

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

لماذا مات النظام؟

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

السؤال الخطابي: هل كان من المفترض أن ينكسر الخادم بسبب الحمل الزائد؟ هل يفعلون ذلك؟

نحن محاكاة حالة تعطل الخادم

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

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

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

سيسمح هذا النهج بـ:

• النظر في ما سيحدث في أحسن الأحوال ؛
• تأخذ مقاييس دقيقة.

التنقل المجدول:

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

لماذا تبين أن الرسم البياني لطلب العميل (الأزرق في الرسم التخطيطي) يكون كذلك؟ عادة ، ينمو جدول الطلبات في مطاعم البيتزا لدينا بسلاسة في الصباح ويتناقص في المساء. لكننا نلاحظ ثلاث قمم على خلفية المنحنى الموحد المعتاد. لم يتم اختيار هذا الشكل من الرسم البياني للنموذج عن طريق الصدفة ، بل بالأحرى. وُلد النموذج أثناء التحقيق في واقعة حقيقية مع خادم مركز اتصال البيتزا في روسيا خلال كأس العالم.

حالة "كأس العالم"

جلسنا وانتظرنا لمزيد من الطلبات. تم الإعداد للبطولة ، والآن ستكون الخوادم قادرة على اجتياز اختبار القوة.

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

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

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

ستأتي القمة الثالثة عندما تنتهي المباراة. المشجعين والنظام ينتظر عقوبة.

نحن نحلل أسباب تعطل الخادم

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

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

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



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



مرة أخرى الجدول الزمني كله. يمكن أن نرى أن التزامن يتحول إلى برية. يظهر جبل ضخم.



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

ولكن من أين أتى هذا الجبل الضخم؟ لقد مرت أكبر ذروة الحمل لفترة طويلة!

القانون الصغير

قانون ليتل يحكم التزامن.

L (عدد العملاء داخل النظام) = λ (سرعة إقامتهم) ∗ W (الوقت الذي يقضونه داخل النظام)

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



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



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

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

هل سنلعب؟

التفسير مع التكاملات معقد إذا كنت لا تتذكر الرياضيات. أنا هنا أقترح الاحماء ولعب اللعبة.

لعبة رقم 1

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

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

في الفترة الثانية ، يتم طلب طبقة آخر ، والآن كلتا المعالجات مشغولتان. لقد قاموا بوحدة عمل واحدة للاستعلامين الأولين. يبقى إكمال وحدات 1 و 2 للطلب الأول والثاني ، على التوالي.

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



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

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



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

نواصل ثلاث فترات أخرى. في انتظار الإجابات.
- خادم ، مرحبا!
- ...



"مكالمتك مهمة جدا بالنسبة لنا ..."



حسنا ، في النهاية جاء الجواب على الطلب الثاني. أوقات الاستجابة هي ضعف ما هو متوقع.



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

لقد دخل خادمنا إلى حالة غير مرغوب فيها ، والتي لن يخرج منها من تلقاء نفسه. انتهت اللعبة

ما الذي يميز حالة GameOver بالخادم؟

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

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

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

وماذا توقعنا فعلا؟! بعد كل شيء ، لقد قدمنا ​​عن قصد للخادم مقدارًا من العمل لم يتمكن من معالجته.

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



هيا نلعب مرة أخرى.

لعبة رقم 2

المتطلبات الأساسية : مرة أخرى ، لدينا وحدتان من وحدات المعالجة المركزية ، وهما نفس المهام المكونة من 3 وحدات ، ونصل كل فترة ، ولكن الآن سنقوم بتعيين الحارس ، وستكون المهام ذكية - إذا رأوا أن قائمة الانتظار هي 2 ، فسيعودون إلى المنزل على الفور.





الطلب الثالث جاء. في هذه الفترة يقف في الطابور. لديه الرقم 3 في نهاية الفترة. لا توجد أرقام كسرية في الوحدات المتبقية ، لأن وحدتي CPU تقومان بمهمتين ، واحدة لفترة.

على الرغم من أن لدينا ثلاثة طلبات ، فإن درجة التزامن داخل النظام = 2. والثالث في قائمة الانتظار ولا يتم حسابه.



جاء الرابع - نفس الصورة ، على الرغم من تراكم المزيد من العمل بالفعل.


...
...

في الفترة السادسة ، تم إكمال الطلب الثالث بتأخر ثالث ، ودرجة التزامن هي بالفعل = 4.



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

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



يمكن تكرار الموقف إلى ما لا نهاية ، بينما يظل وقت تنفيذ الاستعلام على نفس المستوى - تمامًا ضعف المدة التي نرغب فيها.



نرى أن وجود قيود بسيطة على مستوى التزامن يحل مشكلة صلاحية الخادم.

كيفية زيادة صلاحية الخادم من خلال حد مستوى التزامن

يمكنك كتابة أبسط "الحارس" نفسك. أدناه هو رمز باستخدام إشارة. لا يوجد حد لطول الخط الخارجي. , .

const int MaxConcurrency = 100; SemaphoreSlim bulkhead = new SemaphoreSlim(MaxConcurrency, MaxConcurrency); public async Task ProcessRequest() { if (!await bulkhead.WaitAsync()) { throw new OperationCanceledException(); } try { await ProcessRequestInternal(); return; } finally { bulkhead.Release(); } } 

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

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

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

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

تجارب الاستعلام

نلقي نظرة على هذا الوفاة آخر مرة ، ونحن لن نرى هذا مرة أخرى.

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

100 في الداخل ، 100 في الخارج

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

مستوحاة من النجاح ، وسنحاول التأكد من أنه لم يرتد على الإطلاق. دعونا نحاول زيادة طول قائمة الانتظار.

100 في الداخل ، 500 في الخارج

حصلت على أفضل ، ولكن الذيل نمت. هذه هي الطلبات التي يتم تنفيذها لفترة طويلة في وقت لاحق.

100 في الداخل ، 1000 في الخارج

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



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

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

هناك خطر آخر - قد لا يتم تصميم مكونات النظام الأخرى لمثل هذا السلوك على الخادم ، وكما نعلم بالفعل ، يتم عرض التزامن على العملاء.

لذلك ، نعود إلى الخيار الأول "100 لكل 100" ونفكر في كيفية زيادة قدراتنا.

الفائز - 100 في الداخل ، 100 في الخارج

¯ \ _ (ツ) _ / ¯

مع هذه المعلمات ، فإن أكبر تدهور في وقت التشغيل هو بالضبط ضعف "الاسمية". في الوقت نفسه ، هو تدهور بنسبة 100 ٪ في وقت تنفيذ الاستعلام.

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

في الواقع ، نحن لا نحاول إنشاء قائمة انتظار ، نحن نحاول حماية أنفسنا من تقلبات الحمل. هنا ، تمامًا كما هو الحال في تحديد المعلمة الأولى للحاجز (الكمية داخل) ، من المفيد تحديد التقلبات في الحمل التي قد يسببها العميل. لذلك سوف نعرف في أي الحالات ، وبشكل عام ، سوف نفتقد الربح من الخدمة المحتملة.

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

التشخيص والعلاج

نحن نتعامل مع التزامن غير المنضبط مع العزلة بالجملة.
هذه الطريقة ، مثلها مثل تلك التي تمت مناقشتها في هذه السلسلة من المقالات ، يتم تنفيذها بسهولة بواسطة مكتبة Polly .

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

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

قد تشمل التدابير الإضافية التي لا تتناولها دراستنا ، على سبيل المثال ، القياس الديناميكي.