تقنية إعادة التشغيل السريع بدلاً من الحفاظ على الحالة الجيدة (التوافر والاتساق)
https://stackoverflow.com/questions/1435188
-
07-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
كم مرة تحل مشاكلك عن طريق إعادة تشغيل جهاز الكمبيوتر أو جهاز التوجيه أو البرنامج أو المتصفح؟أو حتى عن طريق إعادة تثبيت نظام التشغيل أو مكون البرنامج؟
يبدو أن هذا هو النمط الشائع عندما يكون هناك شك في أن مكون البرنامج لا يحافظ على حالته بالطريقة الصحيحة، ثم تحصل على الحالة الأولية عن طريق إعادة تشغيل المكون.
لقد سمعت أن Amazon/Google لديها مجموعة من العقد المتعددة.ومن الخصائص المهمة لكل عقدة أنها يمكن إعادة تشغيلها خلال ثوانٍ.لذا، إذا فشل أحدهم، فإن إعادته إلى حالته الأولية هو مجرد مسألة إعادة تشغيله.
هل هناك أي لغات/أطر/أنماط تصميم تستفيد من هذه التقنية كمواطن من الدرجة الأولى؟
يحرر الرابط الذي يصف بعض المبادئ وراء أمازون بالإضافة إلى المبادئ العامة للتوفر والاتساق:http://www.infoq.com/presentations/availability-consistency
المحلول
وهذا أمر شائع في عالم الأنظمة المدمجة، وفي الاتصالات السلكية واللاسلكية.إنه أقل شيوعًا في العالم القائم على الخادم.
هناك مجموعة بحثية قد تكون مهتمًا بها.لقد كانوا يعملون على الحوسبة الموجهة نحو الاسترداد أو "ROC".المبدأ الأساسي في ROC هو أن الحالة الأنظف والأفضل والأكثر موثوقية التي يمكن أن يكون فيها أي برنامج تكون بعد بدء التشغيل مباشرةً.لذلك، عند اكتشاف خطأ، يفضلون إعادة تشغيل البرنامج بدلاً من محاولة التعافي من الخطأ.
يبدو بسيطا بما فيه الكفاية، أليس كذلك؟حسنًا، لقد ذهبت معظم الأبحاث إلى تنفيذ هذه الفكرة.والسبب هو بالضبط ما أشرت إليه أنت والمعلقون الآخرون:عمليات إعادة تشغيل نظام التشغيل بطيئة جدًا بحيث لا يمكن اعتبارها طريقة استرداد قابلة للتطبيق.
تعتمد ROC على ثلاثة أجزاء رئيسية:
- طريقة لاكتشاف الأخطاء في أقرب وقت ممكن.
- وسيلة لعزل المكون المعيب مع الحفاظ على بقية النظام.
- إعادة التشغيل على مستوى المكونات.
يتمثل الاختلاف الرئيسي الحقيقي بين ROC وأسلوب "إعادة التشغيل الليلي" النموذجي في أن ROC هي استراتيجية تكون فيها عمليات إعادة التشغيل بمثابة رد فعل.ما أعنيه هو أن معظم البرامج تتم كتابتها بدرجة معينة من معالجة الأخطاء واستردادها (الرمي والالتقاط، والتسجيل، وتكرار المحاولة، وما إلى ذلك). وسيقوم برنامج ROC باكتشاف الخطأ (الاستثناء) و في الحال مخرج.إن الخلط بين النموذجين يتركك مع أسوأ ما في العالمين --- انخفاض الموثوقية والأخطاء.
نصائح أخرى
هذا في الواقع نادر جدًا في عالم يونكس/لينكس.تم تصميم هذه الأنظمة (وكذلك النوافذ) لحماية نفسها من العمليات السيئة التصرف.أنا متأكد من أن Google لا تعتمد على عمليات إعادة التشغيل الصعبة لتصحيح البرامج التي أسيء استخدامها.أود أن أقول إنه لا ينبغي استخدام هذه التقنية وإذا قال شخص ما أن الطريق الأعظم لاستعادة برامجه يجب أن تبحث عن شيء آخر!
عادةً ما تحتوي وحدات التحكم الدقيقة على مؤقت مراقبة، والذي يجب إعادة ضبطه (بواسطة سطر من التعليمات البرمجية) بين الحين والآخر وإلا سيتم إعادة ضبط وحدة التحكم الدقيقة.يؤدي ذلك إلى منع البرنامج الثابت من التعلق في حلقة لا نهاية لها، أو التعثر في انتظار الإدخال، وما إلى ذلك.
يتم أحيانًا تعيين الذاكرة غير المستخدمة إلى تعليمات تؤدي إلى إعادة التعيين، أو الانتقال إلى نفس الموقع الذي يبدأ منه وحدة التحكم الدقيقة عند إعادة تعيينه.سيؤدي هذا إلى إعادة ضبط وحدة التحكم الدقيقة إذا انتقلت بطريقة أو بأخرى إلى موقع خارج ذاكرة البرنامج.
قد تحتوي الأنظمة المضمنة على ميزة نقطة تفتيش حيث يتم حفظ المكدس الحالي كل n مللي ثانية.تكون الذاكرة غير متطايرة عند إعادة تشغيل الطاقة (أي مدعومة بالبطارية)، لذلك عند بدء تشغيل الطاقة، يتم إجراء اختبار لمعرفة ما إذا كان الرمز يحتاج إلى الانتقال إلى نقطة تفتيش قديمة، أو ما إذا كان نظامًا جديدًا.
سأخمن أنه يتم استخدام تقنية مماثلة (ولكنها أكثر تعقيدًا) في Amazon/Google.
على الرغم من أنني لا أستطيع التفكير في نمط التصميم في حد ذاته، إلا أنه من خلال تجربتي، يكون نتيجة "الاختيار معطل" من المطورين.
لقد رأيت موقعًا يضم 50 مستخدمًا يعطل كلاً من SQL Server Enterprise Edition (مع قاعدة بيانات بحجم 750 ميجابايت) وخادم Novell بسبب سوء إدارة الاتصال إلى جانب المكالمات الزائدة وعدم التخزين المؤقت.كان نوفيل دائماً الجاني وفقًا للمطورين حتى عثرنا على مكالمة "CloseConnection" مفقودة في المكتبة الأساسية.بحلول ذلك الوقت، تم إنفاق الآلاف، دون جدوى، على الترقيات لمعالجة هذا السطر المفقود من التعليمات البرمجية.
(لماذا كان لديهم إصدار Enterprise Edition كان خارج نطاق فهمي، لذا لا تسأل!!)
إذا نظرت إلى لغات البرمجة النصية مثل php التي تعمل على Apache، فإن كل استدعاء يبدأ عملية جديدة.في الحالة الأساسية لا توجد حالة مشتركة بين العمليات وبمجرد انتهاء الاستدعاء يتم إنهاء العملية.
تعتبر المزايا أقل عبئًا على إدارة الموارد حيث سيتم إصدارها عند انتهاء العملية وحاجة أقل لمعالجة الأخطاء نظرًا لأن العملية مصممة بحيث تفشل بسرعة ولا يمكن تركها في حالة غير متناسقة.
لقد رأيته في أماكن قليلة على مستوى التطبيق (تطبيق يعيد تشغيل نفسه في حالة تفجيره).
لقد قمت بتنفيذ النمط على مستوى التطبيق، حيث تبدأ خدمة القراءة من ملفات Dbase في الحصول على أخطاء بعد قراءة عدد x من المرات.فهو يبحث عن خطأ معين تم طرحه، وإذا رأى هذا الخطأ، تستدعي الخدمة تطبيق وحدة التحكم الذي يقتل العملية ويعيد تشغيل الخدمة.إنه أمر سخيف، وأنا أكرهه، لكن في هذا الموقف بالذات، لم أتمكن من العثور على إجابة أفضل.
وتذكر أن IIS لديه ميزة مضمنة تعمل على إعادة تشغيل تجمع التطبيقات في ظل ظروف معينة.
وفي هذا الصدد، تعد إعادة تشغيل الخدمة خيارًا لأي خدمة على Windows كأحد الإجراءات التي يجب اتخاذها عند فشل الخدمة.
