تحديات السحابة: المزامنة

10 دقائق

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

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

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

للمتابعة اعتماداً على مثال المهام $A$ و$B$، دعونا نفترض وجود مجموعة أكبر من المهام: $\lbrace A، B، C، \cdots، Z \rbrace$. لضمان الاستثناء المتبادل، قد تنتظر المهمة $A$ اعتماداً على المهمة $B$، إذا كانت $B$ تحمل قفلاً تطلبه $A$. وبالمقابل، قد تنتظر المهمة $B$ اعتماداً على المهمة $C$، إذا كانت $C$ تحمل قفلاً تطلبه $B$. ويمكن أن تستمر سلسلة "الانتظار الاعتمادي" طوال الطريق حتى تصل إلى المهمة $Z$. وعلى وجه التحديد، قد تنتظر المهمة $C$ اعتماداً على المهمة $D$، وقد تنتظر المهمة $D$ اعتماداً على المهمة $$، ويستمر الحال وصولاً إلى المهمة $Y$، والتي قد تنتظر أيضاً اعتماداً على المهمة $Z$. وعادةً ما يشار إلى سلسلة "الانتظار الاعتمادي" هذه بالإغلاق المتعدي. وعندما يحدث إغلاق متعدي، من المتوقع أن يظهر انتظار دائري. وهذا الوضع يؤدي عادةً إلى حالة توقف تام شديدة يمكن أن تصيب أي برنامج / نظام موزع بالكامل بحالة توقف إجباري. وأخيراً، نلاحظ أن علاقة الانتظار الاعتمادي تكمن في صميم كل آلية من آليات الاستثناء المتبادل. وعلى وجه الخصوص، لا يوجد بروتوكول استثناء متبادل، مهما بلغت كفاءته، يتمكن من منعه.² وفي السيناريوهات العادية، تتوقع أي مهمة حالة "الانتظار الاعتمادي" لفترة زمنية محدودة (معقولة). ولكن ماذا يحدث لو تعرضت مهمة تحمل قفلاً/رمزاً مميزاً للتعطل؟ هذا السيناريو يقودنا إلى صعوبة كبيرة أخرى للبرامج الموزعة، وهي التسامح مع الخطأ.

هل تعلم؟

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

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

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

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

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

لمعالجة هذين العائقين الرئيسيين للخوارزميات المركزية، تقترح الخوارزميات اللامركزية تقسيم المنسق المركزي إلى منسقين متعددين.¹ وبالتالي، لكي تحصل أي مهمة على إذن (كتابة)، فإنها تحتاج إلى الحصول على أغلبية الأصوات من المنسقين (انظر الوحدة 4 في هذه الوحدة النمطية لمراجعة مقدمة حول آليات التصويت). ومن الواضح أن الحصول على هذه الأذون يجعل البرنامج الموزع أقل عرضة لـ SPOF. وبشكل أكثر دقة، يمكن لبرنامج موزع مع خوارزمية لا مركزية متبادلة في نطاق محدود، أن يتسامح مع $K$ من أصل $2K + 1$ من حالات فشل المنسق.¹ كذلك، تتخلص الخوارزميات اللامركزية من ازدحام الأداء الذي يظهر في الخوارزميات المركزية. الخوارزميات اللامركزية أكثر تعقيداً في التنفيذ والصيانة من الخوارزميات المركزية. وبشكل عام، يمكن أن تعيق صعوبات التنفيذ والصيانة قابلية التوسع، خاصة إذا زاد عدد رسائل التحكم بشكل كبير.

المراجع

أ. س. تاننباوم وإم. في. ستين (12 أكتوبر 2006). الأنظمة الموزعة: المبادئ والنماذج قاعة برينتيس، النسخة الثانية
إم. هيرليهي ون. شافيت (14 مارس 2008). فن البرمجة متعددة المعالجات مورغان كوفمان، النسخة الأولى

افترض وجود الدالة التالية:

transaction (Account source, Account destination, double amount)
{
  Acquire lock on source;
  Acquire lock on destination;
  withdraw(from, amount);
  deposit(to, amount);
  Release lock on destination;
  Release lock on source;
}

افترض مبدئياً أن الحسابين A وB في كل منهما 100 دولار ويتم تنفيذ العمليات التالية في نفس الوقت، بحيث أن كلا العمليتين يحصلا على قفل على حساب المصدر (كما هو مشار إليه في السطر رقم 3 في دالة المعاملة) في نفس الوقت:

1 Transaction(A,B,50); and Transaction(B,A,10);

ماذا ستكون النتيجة؟

A سيكون لديه 140 دولاراً وB سيكون لديه 60 دولاراً.

A سيكون لديه 60 دولاراً وB سيكون لديه 90 دولاراً.

A سيكون لديه 110 دولارات وB سيكون لديه 90 دولاراً.

لن تنتهي المعاملات أبداً بسبب حالة توقف تام.

عليك الإجابة على كل الأسئلة قبل مراجعة عملك.

الملاحظات

هل كانت هذه الصفحة مفيدة؟

تحديات السحابة: المزامنة

‏‫اختبر معلوماتك

الملاحظات