Scala + Akka: كيفية تطوير مجموعة متعددة المتاحة للغاية

Question

نقوم بتطوير نظام خادم في Scala + Akka للعبة التي ستخدم العملاء في Android و iPhone و Second Life. هناك أجزاء من هذا الخادم تحتاج إلى أن تكون متاحة للغاية ، تعمل على أجهزة متعددة. إذا مات أحد هذه الخوادم (من فشل الأجهزة ، على سبيل المثال) ، يحتاج النظام إلى الاستمرار. أعتقد أنني أريد أن يكون لدى العملاء قائمة بالآلات التي سيحاولون الاتصال بها ، على غرار كيفية عمل Cassandra.

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

هل هناك أي أمثلة تُظهر هذا النوع من التسامح مع أخطاء الأجهزة لـ Akka؟ أو هل لديك أي أفكار حول طرق جيدة لتحقيق ذلك؟

حتى الآن ، فإن أفضل إجابة تمكنت من التوصل إليها هي دراسة مستندات Erlang OTP ، والتأمل عليها ، ومحاولة معرفة كيفية وضع نظامي معًا باستخدام لبنات البناء المتاحة في Akka.

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

Answer 1

HA وإدارة الحمل هي جانب مهم للغاية من قابلية التوسع ومتاح كجزء من AkkaSource عرض تجاري.

Answer 2

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

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

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

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

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

تأكد من أن قائمة المضيفين الخاصة بك هي أسماء المضيف الفعلية ، وليس IPs ، التي تمنحك المزيد من المرونة على المدى الطويل (أي سيكون "دائمًا لديك" ass1.example.com ، host2.example.com ... إلخ. يمكنك نقل البنية التحتية وتغيير IPS).

Answer 3

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

Answer 4

2 سنت ..

"كيفية مشاركة الحالة بين آلات متعددة بطريقة ما إذا كان أحدها يسير في العمل".

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

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

باستخدام Akka ، نحصل على النبع بين العقد تقريبًا مجانًا. هذا يعني أن أي عقدة تتعامل مع طلب قد يحتاج إلى التفاعل مع إجمالي/كيان على عقد أخرى يمكنه القيام بذلك باستخدام أجهزة التحكم عن بعد.

ما حددته هنا هو عام للغاية ولكنه يعطي مقاربة لتسامح الأخطاء الموزعة مع Akka و Zookeeper. قد يساعد أو لا يساعد. أتمنى أن يفعل ذلك.

كل التوفيق ، آندي