منخفضة الكمون على نطاق واسع وضع الرسائل في قائمة انتظار

Question

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

لنفترض كنت بناء شيء على رأس القائمة المفتوحة البروتوكولات و أريد أن تخدم 1,000,000 المتزامن لاعبين فقط في نطاق المشكلة.

لنفترض أن كل لاعب لديه رسالة واردة طابور (من أجل الدردشة و غيرها), و واحد في المتوسط أكثر واردة انتظار الرسائل (النقابات, مناطق, حالات, مزاد, ...) لذلك علينا 2,000,000 قوائم الانتظار.لاعب سوف تستمع إلى 1-10 طوابير في كل مرة.كل طابور سوف يكون في المتوسط ربما 1 رسالة في الثانية ، ولكن بعض طوابير سوف يكون أعلى بكثير من معدل أعلى عدد من المستمعين (ويقول ، "الكيان موقع" طابور مستوى سبيل المثال).دعونا نفترض أن هناك أكثر من 100 ميلي ثانية من نظام الطابور الكمون ، وهو موافق أقل ما يقال المنحى الألعاب (ولكن ليس الألعاب مثل زلزال أو غير واقعي بطولة).

من النظم الأخرى, وأنا أعلم أن تخدم 10 ، 000 من المستخدمين على واحد 1U أو شفرة مربع توقع معقول (على افتراض أن هناك شيء آخر مكلفة مثل محاكاة الفيزياء أو غيرها).

حتى مع العارضة نظام المجموعات حيث الاتصال العملاء إلى الاتصال العبارات ، والتي بدورها الاتصال إلى قائمة انتظار الرسائل خوادم ، 10 ، 000 من المستخدمين في بوابة 100 بوابة آلات 20,000 رسالة طوابير في انتظار الخادم مع 100 طابور الآلات.مرة أخرى, فقط من أجل العامة النطاق.عدد من الاتصالات على كل MQ الجهاز يكون صغير:حوالي 100 ، التحدث إلى كل من العبارات.عدد الاتصالات على بوابات سيكون الكثير العالي:10,100 للعملاء + وصلات إلى جميع طابور الخوادم.(على رأس هذا إضافة بعض اتصالات لعبة محاكاة العالم الخوادم أو ما شابه, ولكن أنا أحاول أن تبقي منفصلة)

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

هل لدى أحدكم أي النهار تجربة مع هذه التقنيات ، أو تطبيقات منها ، التي يمكنك مشاركتها ؟

Answer 1

@MSalters

"إعادة" انتظار الرسائل':

RabbitMQ الافتراضي العملية هو بالضبط ما كنت وصف:عابر pubsub.ولكن مع TCP بدلا من UDP.

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

النموذج الذي وصف هو السلوك الافتراضي الذي هو عابر "النار وننسى" ، توجيه رسائل إلى أي مكان المتلقين.الناس استخدام RabbitMQ للقيام الإرسال المتعدد على اكتشاف EC2 لهذا السبب فقط.يمكنك الحصول على نوع UDP السلوكيات على الإرسال TCP pubsub.أنيق ؟

إعادة UDP:

أنا لست متأكدا مما إذا UDP أن تكون مفيدة هنا.إذا قمت بإيقاف Nagling ثم RabbitMQ رسالة واحدة ذهاب وإياب الكمون (العميل-وسيط-العميل) تم قياسها في 250-300 ميكروثانية.انظر هنا للمقارنة مع ويندوز الكمون (الذي كان أعلى قليلا) http://old.nabble.com/High%28er%29-latency-with-1.5.1--p21663105.html

لا أستطيع التفكير في العديد من الالعاب التي تحتاج للتوصيل من وإلى زمن أقل من 300 ميكروثانية.يمكن لك الحصول على أقل 300us مع TCP.TCP النوافذ هو أكثر تكلفة من الخام UDP, ولكن إذا كنت تستخدم UDP الذهاب أسرع ، إضافة مخصص خسارة استرداد أو seqno/ack/إرسال مدير ثم أنه قد يبطئ أنت إلى أسفل مرة أخرى.كل هذا يتوقف على حالة الاستخدام.إذا كنت حقا بحاجة إلى استخدام UDP و كسول acks وهلم جرا, ثم هل يمكن أن غزة بها RabbitMQ TCP وربما فعل ذلك.

آمل أن يساعد هذا توضيح السبب في أنني أوصى RabbitMQ جون حالة استخدام.

Answer 2

أنا بناء مثل هذا النظام في الواقع.

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

نظام بلدي الحالي من المحتمل استخدام ZeroMQ ، ولكن محدودة إلى حد ما الطريقة ، داخل الكتلة.الاتصالات من العملاء يتم التعامل مع العرف sim.شيطان أنني بنيت باستخدام libev تماما ترابط واحد (و هو عرض جيد جدا التحجيم -- ينبغي أن تكون قادرة على التعامل مع 50,000 اتصالات على مربع واحد دون أي مشاكل-لدينا sim.علامة معدل منخفض جدا على الرغم من ، وليس هناك أي الفيزياء).

XML (وبالتالي XMPP) جدا لا تتناسب مع هذا ، كما عليك ربط وحدة المعالجة المركزية XML طويلة قبل أن تصبح ملزمة على I/O الذي ليس ما تريد.نحن نستخدم جوجل البروتوكول المخازن ، في هذه اللحظة ، وتلك التي تبدو مناسبة تماما لدينا احتياجات خاصة.نحن أيضا باستخدام TCP اتصالات العميل.لدي خبرة في استخدام كل UDP و TCP هذا في الماضي ، كما أشير إلى ذلك من قبل الآخرين ، UDP لديها بعض المزايا, لكنه أكثر قليلا من الصعب العمل مع.

نأمل عندما نكون أقرب قليلا إلى إطلاق, سوف تكون قادرة على تبادل المزيد من التفاصيل.

Answer 3

جون, هذا يبدو مثاليا استخدام حالة AMQP و RabbitMQ.

أنا لست متأكدا لماذا تقول ذلك AMQP المستخدمين في جميع المشاريع الكبيرة من نوع الشركات.أكثر من نصف من عملائنا في 'الشبكة' الفضاء بدءا من كبيرة إلى صغيرة الشركات.الكثير من ألعاب الرهان أنظمة, أنظمة الدردشة ، twittery نوع أنظمة الحوسبة السحابية infras تم بناؤها من RabbitMQ.بل هناك تطبيقات الهاتف المحمول.سير العمل هي مجرد واحدة من العديد من حالات الاستخدام.

ونحن نحاول تتبع ما يجري هنا:

http://www.rabbitmq.com/how.html (تأكد من خلال النقر على قوائم حالات الاستخدام على ديل.icio.لنا أيضا!)

يرجى إلقاء نظرة.نحن هنا للمساعدة.لا تتردد في مراسلتنا على البريد الإلكتروني info@rabbitmq.com أو ضرب لي على تويتر (@بعملية).

Answer 4

FWIW, في الحالات التي تكون فيها نتائج المتوسطة ليست مهمة (مثل تحديد المواقع معلومات) Qpid لديه "الماضي-قيمة قائمة الانتظار" التي يمكن أن توفر فقط القيمة الأخيرة إلى المشترك.

Answer 5

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

لهذا السبب, حتى لا تذهب بالقرب XML الأساسية الواجهات.كتلة الملقم سيتم توزيع 2 مليون رسالة في الثانية.التي يمكن بسهولة أن 2-20 GB/sec XML!ومع ذلك ، فإن معظم الرسائل سوف يكون قليل قوائم ، في حين أن معظم قوائم الانتظار في الواقع انخفاض حركة المرور.

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

أيضا لأسباب مشابهة ، لا تفترض أن رسالة طابور العمارة هو أفضل لجميع comminication ل احتياجات التطبيق الخاص بك لديه.اتخاذ الخاص بك "الكيان موقع في مثيل" على سبيل المثال.هذه حالة كلاسيكية حيث يمكنك لا تريد ضمان تسليم الرسالة.السبب في أن كنت بحاجة إلى مشاركة هذه المعلومات لأنه يتغير في كل وقت.لذا ، إذا كانت الرسالة فقد كنت لا تريد لقضاء بعض الوقت لاستعادة.كنت فقط إرسال القديمة locatiom المتضررة الكيان.بدلا من ذلك, كنت ترغب في إرسال الحالي موقع هذا الكيان.التكنولوجيا الحكيم هذا يعني أنك تريد UDP لا TCP و مخصص الخسائر آلية استرداد.