شركة Variti متخصصة في الحماية ضد هجمات البوتات وهجمات DDoS ، وتجري أيضًا اختبارات التحمل والتحميل. نظرًا لأننا نعمل كخدمة دولية ، من المهم للغاية بالنسبة لنا ضمان التبادل المستمر للمعلومات بين الخوادم والمجموعات في الوقت الفعلي. في مؤتمر Saint HighLoad ++ 2019 ، أخبر مطور Variti Anton Barabanov كيف نستخدم UDP و Tarantool ، لماذا أخذنا هذه المجموعة ، وكيف اضطررنا إلى إعادة كتابة وحدة Tarantool من Lua إلى C.يمكنك أيضًا قراءة
ملخص التقرير
عبر الرابط ، ومشاهدة الفيديو أدناه أسفل المفسد.
عندما بدأنا في تقديم خدمة تصفية حركة المرور ، قررنا على الفور عدم التعامل مع نقل IP ، ولكن لحماية HTTP و API وخدمات الألعاب. وبالتالي ، فإننا ننهي حركة المرور على مستوى L7 في بروتوكول TCP ونمررها. الحماية على L3 و 4 في نفس الوقت تحدث تلقائيا. يُظهر الرسم التوضيحي أدناه مخطط الخدمة: تمر طلبات الأشخاص عبر مجموعة ، أي الخوادم ومعدات الشبكة ، ويتم تصفية برامج الروبوت (كما هو موضح بالشبح).
من أجل التصفية ، من الضروري تقسيم حركة المرور إلى طلبات منفصلة ، وتحليل الجلسات بدقة وسرعة ، وبما أننا لا نحظر عناوين IP ، ونعرّف الروبوتات والأشخاص الموجودين داخل الاتصال من عنوان IP نفسه.
ما يحدث داخل الكتلة
داخل المجموعة ، لدينا عقد ترشيح مستقلة ، أي تعمل كل عقدة بمفردها وفقط مع حركة المرور الخاصة بها. يتم توزيع حركة المرور بشكل عشوائي بين العقد: إذا تم ، على سبيل المثال ، تلقي 10 اتصالات من مستخدم واحد ، فسوف تتباعد جميعها على خوادم مختلفة.
لدينا متطلبات أداء صارمة للغاية حيث يوجد عملائنا في بلدان مختلفة. وإذا قام مستخدم من سويسرا ، على سبيل المثال ، بزيارة أحد المواقع الفرنسية ، فسيواجه بالفعل 15 مللي ثانية من تأخير الشبكة بسبب زيادة في حركة المرور. لذلك ، لا يحق لنا إضافة 15-20 مللي ثانية أخرى داخل مركز المعالجة الخاص بنا - سيستمر الطلب لفترة طويلة للغاية. بالإضافة إلى ذلك ، إذا قمنا بمعالجة كل طلب HTTP لـ 15-20 مللي ثانية ، فإن الهجوم البسيط البالغ 20 ألف RPS سيضيف المجموعة بأكملها. هذا ، بالطبع ، غير مقبول.
كان الشرط الآخر بالنسبة لنا ليس فقط تتبع الطلب ، ولكن أيضًا فهم السياق. افترض أن المستخدم يفتح صفحة ويب ويرسل طلب شرطة مائلة. بعد ذلك ، يتم تحميل الصفحة ، وإذا كانت HTTP / 1.1 ، فإن المستعرض يفتح 10 اتصالات للخلفية وفي 10 تدفقات يطلب الإحصائيات والديناميكيات ، ويقدم طلبات ajax واستعلامات فرعية. إذا ، بدلاً من بروكسي استعلام فرعي ، في عملية إرسال الصفحة ، تبدأ في التفاعل مع المستعرض وتحاول إعطائه ، على سبيل المثال ، JS Challenge للاستعلام الفرعي ، فعلى الأرجح سوف تقوم بتحطيم الصفحة. بناءً على الطلب الأول ، يمكنك إعطاء اختبار CAPTCHA (على الرغم من أنه أمر سيء) أو تحديات JS ، وإعادة توجيه ، ومن ثم سيعالج أي مستعرض كل شيء بشكل صحيح. بعد الاختبار ، من الضروري نشر المعلومات على جميع المجموعات بأن الجلسة شرعية. إذا لم يكن هناك تبادل للمعلومات بين المجموعات ، فإن العقد الأخرى ستتلقى الجلسة من المنتصف ولن تعرف ما إذا كانت ستتخطاها أم لا.
من المهم أيضًا الاستجابة بسرعة لجميع عمليات زيادة الحمل والتغيرات في حركة المرور. إذا قفز شيء على عقدة واحدة ، بعد 50-100 ميلي ثانية ، ستحدث قفزة على جميع العقد الأخرى. لذلك ، من الأفضل معرفة العقد بالتغييرات مقدمًا وتعيين معلمات الحماية مقدمًا بحيث لا تحدث أي قفزة على جميع العقد الأخرى.
كانت خدمة ما بعد الترميز هي خدمة إضافية للحماية من البوتات: وضعنا بكسل على الموقع ، وكتابة معلومات بوت / شخص وإرسال هذه البيانات عبر API. يجب أن تبقى هذه الأحكام في مكان ما. وهذا هو ، إذا تحدثنا سابقًا عن التزامن داخل كتلة ، فنحن الآن نضيف تزامن المعلومات بين المجموعات أيضًا. نعرض أدناه مخطط الخدمة على مستوى L7.
بين المجموعات
بعد أن صنعنا الكتلة ، بدأنا في التوسع. نحن نعمل من خلال BGP anycast ، أي يتم الإعلان عن شبكاتنا الفرعية من جميع التجمعات ويأتي المرور إلى الأقرب. ببساطة ، يتم إرسال طلب من فرنسا إلى مجموعة في فرانكفورت ، ومن سان بطرسبرج إلى كتلة في موسكو. يجب أن تكون المجموعات مستقلة. تدفقات الشبكة مسموح بها مستقلة.
لماذا هذا مهم؟ لنفترض أن شخصًا يقود سيارة ، ويعمل مع موقع إلكتروني من الإنترنت عبر الهاتف المحمول ويعبر روبيكون معينًا ، وبعد ذلك تنتقل حركة المرور فجأة إلى مجموعة أخرى. أو حالة أخرى: تم إعادة بناء مسار حركة المرور لأن مفتاح التبديل أو جهاز التوجيه قد توقف ، في مكان ما ، قطع قطاع الشبكة. في هذه الحالة ، نوفر للمتصفح (على سبيل المثال ، في ملفات تعريف الارتباط) معلومات كافية بحيث يمكن عند التبديل إلى مجموعة أخرى ، إبلاغ المعلمات الضرورية عن الاختبارات التي تم اجتيازها أو فشلها.
بالإضافة إلى ذلك ، يجب عليك مزامنة وضع الحماية بين الكتل. هذا مهم في حالة الهجمات ذات الحجم المنخفض ، والتي تتم في أغلب الأحيان تحت غطاء الفيضان. نظرًا لأن الهجمات تتم بالتوازي ، يعتقد الناس أن موقعهم يكسر الفيضان ولا يرون هجومًا صغير الحجم. للحالة عندما يأتي حجم منخفض إلى مجموعة واحدة ، وتدفق إلى مجموعة أخرى ، من الضروري تزامن وضع الحماية.
وكما ذكرنا سابقًا ، فإننا نقوم بالمزامنة بين الكتل والأحكام ذاتها التي تتراكم وتعطى بواسطة API. في هذه الحالة ، يمكن أن يكون هناك العديد من الأحكام ويجب مزامنتها بشكل موثوق. في وضع الحماية ، يمكنك فقد شيء داخل المجموعة ، ولكن ليس بين المجموعات.
تجدر الإشارة إلى أن هناك كمون كبير بين المجموعات: في حالة موسكو وفرانكفورت ، يبلغ 20 مللي ثانية. لا يمكن تقديم الطلبات المتزامنة هنا ؛ كل التفاعل يجب أن يكون في وضع غير متزامن.
نعرض أدناه التفاعل بين المجموعات. M ، l ، p هي بعض المعايير التقنية للتبادل. U1 ، u2 هو علامة المستخدم غير شرعية وشرعية.
التفاعل الداخلي بين العقد
في البداية ، عندما قدمنا الخدمة ، بدأ التصفية على مستوى L7 على عقدة واحدة فقط. هذا يعمل بشكل جيد لاثنين من العملاء ، ولكن ليس أكثر. عند التوسع ، أردنا تحقيق أقصى قدر من الاستجابة والحد الأدنى من زمن الوصول.
كان من المهم تقليل موارد وحدة المعالجة المركزية (CPU) التي تنفق على معالجة الحزم ، لذلك فإن التفاعل من خلال ، على سبيل المثال ، لن يكون HTTP مناسبًا. كان من الضروري أيضًا ضمان الحد الأدنى من استهلاك النفقات العامة ليس فقط لموارد الحوسبة ، ولكن أيضًا لمعدل الرزم. ومع ذلك ، فإننا نتحدث عن تصفية الهجمات ، وهذه مواقف لا يوجد فيها أداء كافٍ بشكل واضح. عادة ، عند إنشاء مشروع ويب ، تكون x3 أو x4 كافية للتحميل ، ولكن لدينا دائمًا x1 ، نظرًا لأن الهجوم واسع النطاق يمكن أن يحدث دائمًا.
هناك مطلب آخر لواجهة التفاعل وهو وجود مكان سنكتب فيه المعلومات ومن ثم يمكننا حساب الحالة التي نحن فيها الآن. ليس سراً أن C ++ يستخدم غالبًا لتطوير أنظمة التصفية. ولكن لسوء الحظ ، تعطل البرامج المكتوبة بلغة C ++ أحيانًا. في بعض الأحيان تحتاج هذه البرامج إلى إعادة التشغيل لتحديثها ، أو على سبيل المثال ، لأن التكوين لم تتم إعادة قراءته. وإذا قمنا بإعادة تشغيل العقدة التي تتعرض للهجوم ، فسنحتاج إلى أخذ السياق الذي توجد فيه هذه العقدة في مكان ما. بمعنى أنه لا ينبغي أن تكون الخدمة بلا جنسية ، ويجب أن تتذكر أن هناك عددًا معينًا من الأشخاص الذين حظرناهم ، ونقوم بالتحقق منهم. يجب أن يكون هناك نفس الاتصال الداخلي حتى تتمكن الخدمة من تلقي مجموعة أولية من المعلومات. كانت لدينا أفكار لوضع بالقرب من قاعدة بيانات معينة ، على سبيل المثال SQLite ، لكننا تجاهلنا بسرعة مثل هذا الحل ، لأنه من الغريب أن نكتب المدخلات والمخرجات على كل خادم ، وهذا سوف يعمل بشكل سيء في الذاكرة.
في الواقع ، نحن نعمل مع ثلاث عمليات فقط. الوظيفة الأولى هي "إرسال" إلى جميع العقد. ينطبق هذا ، على سبيل المثال ، على الرسائل التي تتم مزامنة التحميل الحالي: يجب أن تعرف كل عقدة الحمل الكلي على المورد داخل الكتلة من أجل تتبع القمم. العملية الثانية هي "الحفظ" ؛ فهي تتعلق بأحكام التحقق. أما العملية الثالثة فهي مزيج من "إرسال للجميع" و "حفظ". نحن هنا نتحدث عن رسائل تغيير الحالة التي نرسلها إلى جميع العقد ومن ثم حفظها حتى نتمكن من طرحها. فيما يلي مخطط التفاعل الناتج ، والذي سنحتاج إلى إضافة معلمات للحفظ.
الخيارات والنتيجة
ما هي خيارات الحفاظ على الأحكام التي نظرنا إليها؟ أولاً ، كنا نفكر في الكلاسيكيات ، RabbitMQ ، RedisMQ والخدمة التي تستند إلى TCP الخاصة بنا. لقد رفضنا هذه القرارات لأنها تعمل ببطء. يضيف TCP نفسه x2 إلى معدل الحزمة. بالإضافة إلى ذلك ، إذا أرسلنا رسالة من عقدة واحدة إلى جميع النقاط الأخرى ، فسنحتاج إما إلى الحصول على الكثير من إرسال العقد ، أو يمكن أن تسمم هذه العقدة 1/16 من تلك الرسائل التي يمكن أن ترسلها 16 ماكينة إليها. من الواضح أن هذا غير مقبول.
ونتيجة لذلك ، اتخذنا الإرسال المتعدد UDP ، لأنه في هذه الحالة يكون مركز الإرسال عبارة عن معدات شبكية ، والتي لا تقتصر على الأداء وتتيح لك حل المشكلات تمامًا مع سرعة الإرسال والاستقبال. من الواضح أننا في حالة UDP ، لا نفكر في التنسيقات النصية ، ولكننا نرسل البيانات الثنائية.
بالإضافة إلى ذلك ، أضفنا على الفور التعبئة والتغليف وقاعدة البيانات. لقد أخذنا Tarantool ، أولاً ، لأن مؤسسي الشركة الثلاثة جميعهم لديهم خبرة في العمل مع قاعدة البيانات هذه ، وثانياً ، أنها مرنة قدر الإمكان ، أي أنها أيضًا نوع من خدمة التطبيق. بالإضافة إلى ذلك ، لدى Tarantool CAPI ، والقدرة على الكتابة باللغة C هي مسألة مبدأ بالنسبة لنا لأن الحماية القصوى مطلوبة للحماية من DDoS. لا توجد لغة مترجمة يمكنها توفير أداء كافٍ ، على عكس C.
في المخطط أدناه ، أضفنا قاعدة بيانات داخل الكتلة ، حيث يتم تخزين حالات الاتصال الداخلي.
إضافة قاعدة البيانات
في قاعدة البيانات ، نقوم بتخزين الحالة في شكل سجل للمكالمات. عندما توصلنا إلى كيفية حفظ المعلومات ، كان هناك خياران. كان من الممكن تخزين بعض الحالات مع التحديث المستمر والتغيير ، ولكن يصعب تنفيذه. لذلك ، استخدمنا طريقة مختلفة.
والحقيقة هي أن هيكل البيانات المرسلة عبر UDP هو موحد: هناك توقيت ، نوع من التعليمات البرمجية ، ثلاثة أو أربعة حقول البيانات. لذلك بدأنا في كتابة هذا الهيكل في مساحة Tarantool وأضفنا سجل TTL هناك ، مما يجعل من الواضح أن الهيكل قديم ويجب حذفه. وبالتالي ، يتم تجميع سجل الرسائل في Tarantool ، والذي نقوم بمسحه مع التوقيت المحدد. لحذف البيانات القديمة ، بدأنا في البداية انتهاء الصلاحية. بعد ذلك ، كان علينا أن نتخلى عنه ، لأنه تسبب في بعض المشاكل ، والتي سنناقشها أدناه. حتى الآن ، المخطط: تمت إضافة قاعدتي بيانات بهيكلنا.
كما ذكرنا بالفعل ، بالإضافة إلى تخزين حالات الكتلة ، من الضروري أيضًا مزامنة الأحكام. الأحكام التي نقوم بمزامنة intercluster. وفقًا لذلك ، كان من الضروري إضافة تثبيت إضافي لـ Tarantool. سيكون من الغريب استخدام حل آخر ، لأن Tarantool موجود بالفعل وهو مثالي لخدمتنا. في التثبيت الجديد ، بدأنا في كتابة الأحكام وتكرارها مع مجموعات أخرى. في هذه الحالة ، لا نستخدم السيد / العبد ، ولكن نستخدم السيد / السيد. الآن في Tarantool لا يوجد سوى سيد / سيد غير متزامن ، وهو أمر غير مناسب لكثير من الحالات ، لكن هذا النموذج هو الأفضل بالنسبة لنا. مع الحد الأدنى من زمن الوصول بين الكتل ، فإن النسخ المتماثل المتزامن سيكون في الطريق ، في حين أن النسخ المتماثل غير المتزامن لا يسبب مشاكل.
المشاكل
ولكن لدينا الكثير من المشاكل.
تتعلق الكتلة الأولى من التعقيد بـ UDP : ليس سراً أن البروتوكول يمكنه التغلب على الحزم وفقدها. لقد حللنا هذه المشكلات بطريقة النعامة ، أي ببساطة أخفينا رؤوسنا في الرمال. ومع ذلك ، فإن تلف الحزمة وإعادة ترتيب أماكنها أمر مستحيل معنا ، حيث يتم الاتصال في إطار مفتاح واحد ، ولا توجد اتصالات غير مستقرة ومعدات شبكة غير مستقرة.
قد تكون هناك مشكلة في فقدان الحزمة إذا تجمد الجهاز ، أو يحدث إخراج الإدخال في مكان ما ، أو إذا كانت العقدة مثقلة. إذا حدث تعليق من هذا القبيل لفترة قصيرة من الزمن ، على سبيل المثال ، 50 مللي ثانية ، فهذا أمر فظيع ، ولكن يتم حلها عن طريق زيادة قوائم الانتظار sysctl. وهذا هو ، نحن نأخذ sysctl ، وتكوين حجم قوائم الانتظار والحصول على مخزن مؤقت حيث كل شيء يكمن حتى تبدأ العقدة العمل مرة أخرى. إذا حدث تجميد أطول ، فلن تكون المشكلة هي فقدان الاتصال ، ولكن جزء من حركة المرور التي تذهب إلى العقدة. حتى الآن ، لم يكن لدينا مثل هذه الحالات.
كانت
مشاكل النسخ المتماثل تارانتول أكثر تعقيدا بكثير. في البداية ، لم نأخذ ماجستير / ماجستير ، ولكن نموذج أكثر تقليدية لتشغيل السيد / العبد. وعملت كل شيء بالضبط حتى تولى العبد الحمل الرئيسي لفترة طويلة. نتيجة لذلك ، انتهى انتهاء الصلاحية وحذف البيانات على الرئيسية ، ولكن على العبد لم يكن. وفقا لذلك ، عندما تحولنا عدة مرات من السيد إلى العبد والعودة ، فإن الكثير من البيانات المتراكمة على العبيد قد كسرت كل شيء في مرحلة ما. لذلك من أجل التسامح الكامل مع الخطأ ، اضطررت إلى التبديل إلى النسخ المتماثل الرئيسي / الرئيسي غير المتزامن.
وهنا مرة أخرى نشأت صعوبات. أولاً ، قد تتقاطع المفاتيح بين النسخ المتماثلة المختلفة. لنفترض ، داخل المجموعة ، أننا كتبنا البيانات إلى رئيسي واحد ، وفي هذه المرحلة قطع الاتصال ، وكتبنا كل شيء إلى الرئيسي الثاني ، وبعد أن أجرينا إجراء نسخ متماثل غير متزامن ، اتضح أن نفس المفتاح الأساسي في الفضاء وتكرار النسخ المتماثل.
لقد حللنا هذه المشكلة ببساطة: لقد اتخذنا نموذجًا يحتوي فيه المفتاح الأساسي بالضرورة على اسم عقدة Tarantool التي نكتب إليها. وبسبب هذا ، توقفت النزاعات عن الظهور ، ولكن أصبح الموقف ممكنًا عند تكرار بيانات المستخدم. هذه حالة نادرة للغاية ، لذا فقد أهملناها مرة أخرى. إذا حدث تكرار في كثير من الأحيان ، فإن Tarantool به العديد من الفهارس المختلفة ، لذلك يمكنك دائمًا القيام بإلغاء البيانات المكررة.
هناك مشكلة أخرى تتعلق بالحفاظ على الأحكام وتنشأ عندما لا تظهر البيانات المسجلة على سيد على الآخر ، وقد وصل الطلب بالفعل إلى المعلم الأول. لنكون صادقين ، لم نحل هذه المشكلة بعد ونؤجل صدور الحكم. إذا كان هذا غير مقبول ، فسننظم نوعًا من الضغط على جاهزية البيانات. هكذا تعاملنا مع النسخ المتماثل للماجستير / الرئيسي ومشكلاته.
كانت هناك مجموعة من المشاكل المتعلقة مباشرة بـ Tarantool وبرامج التشغيل ووحدة انتهاء الصلاحية. بعض الوقت بعد الإطلاق ، بدأت الهجمات تأتي إلينا كل يوم ، على التوالي ، أصبح عدد الرسائل التي نحفظها في قاعدة البيانات لمزامنة وتخزين السياق كبيرًا جدًا. وأثناء تجريد البيانات ، تم حذف الكثير من البيانات بحيث توقف جامع البيانات المهملة عن التعامل. لقد حللنا هذه المشكلة عن طريق الكتابة في C الخاصة بنا وحدة انتهاء الصلاحية تسمى IExpire.
ومع ذلك ، مع انتهاء الصلاحية ، هناك صعوبة أخرى لم نتمكن من إدارتها بعد وتكمن في حقيقة أن انتهاء الصلاحية يعمل فقط على سيد واحد. وإذا سقطت عقدة انتهاء الصلاحية ، فستفقد الكتلة الوظيفة الحرجة. لنفترض أننا نقوم بتنظيف جميع البيانات الأقدم من ساعة واحدة - من الواضح أنه إذا كانت العقدة تقع ، على سبيل المثال ، خمس ساعات ، فسيكون مقدار البيانات x5 إلى المعتاد. وإذا حدث هجوم كبير في تلك اللحظة ، أي أن حالتين سيئتين تزامنتا ، فسوف تسقط المجموعة. نحن لا نعرف بعد كيفية التعامل مع هذا.
أخيرًا ، بقيت هناك صعوبات في برنامج تشغيل Tarantool لـ C. عندما أوقفنا الخدمة (على سبيل المثال ، بسبب حالة السباق) ، استغرق الأمر وقتًا طويلاً للعثور على السبب والتصحيح. لذلك ، لقد كتبنا للتو سائق Tarantool. استغرقنا خمسة أيام لتنفيذ البروتوكول إلى جانب الاختبار وتصحيح الأخطاء وتشغيله في الإنتاج ، ولكن لدينا بالفعل الكود الخاص بنا للعمل مع الشبكة.
مشاكل في الخارج
أذكر أن لدينا بالفعل النسخ المتماثل Tarantool جاهزة ، ونحن نعرف بالفعل كيفية مزامنة الأحكام ، ولكن لا توجد بنية أساسية لنقل الرسائل حول الهجمات أو المشاكل بين الكتل حتى الآن.
كان لدينا الكثير من الأفكار المختلفة حول البنية التحتية ، بما في ذلك التفكير في كتابة خدمة TCP الخاصة بنا. ولكن لا يزال هناك وحدة نمطية Tarantool من فريق Tarantool. بالإضافة إلى ذلك ، كان لدينا بالفعل Tarantool مع النسخ المتماثل للمجموعات المتقاطعة ، تم لف "الثقوب" ، أي أنه لم تكن هناك حاجة للذهاب إلى المشرفين واطلب فتح المنافذ أو قيادة حركة المرور. مرة أخرى ، كان الاندماج في ترشيح البرامج جاهزًا.
كانت هناك صعوبة في العقدة المضيفة. افترض أن هناك العقد المستقلة داخل كتلة وتحتاج إلى اختيار العقد التي ستتفاعل مع قائمة انتظار الكتابة. لأن خلاف ذلك سيتم إرسال 16 رسالة أو 16 مرة سيتم طرح نفس الرسالة من قائمة الانتظار. لقد حللنا هذه المشكلة ببساطة: نقوم بتسجيل عقدة مسؤولة في Tarantool في الفضاء ، وإذا كانت العقدة تحترق ، فإننا ببساطة نغير المساحة إذا لم ننسَ. ولكن إذا نسينا ، فهذه مشكلة نريد حلها أيضًا في المستقبل.
أدناه هو مخطط تفصيلي بالفعل من كتلة مع واجهة التفاعل.
ما أريد أن تحسين وإضافة
أولاً ، نريد النشر في IExpire مفتوح المصدر. يبدو لنا أن هذه وحدة مفيدة ، لأنها تتيح لك أن تفعل كل شيء مثل انتهاء الصلاحية ، ولكن مع ما يقرب من الصفر. هناك يجب عليك إضافة فهرس الفرز لإزالة أقدم مجموعة. حتى الآن ، لم نقم بذلك ، لأن العملية الرئيسية في Tarantool بالنسبة لنا هي "الكتابة" ، وسوف يؤدي فهرس إضافي إلى تحميل إضافي بسبب دعمها. نريد أيضًا إعادة كتابة معظم الأساليب في CAPI لتجنب طي قاعدة البيانات.
يبقى السؤال مع اختيار المعلم المنطقي ، لكن يبدو أن هذه المشكلة مستحيلة الحل. أي أنه في حالة سقوط العقدة ذات انتهاء الصلاحية ، يبقى فقط تحديد عقدة أخرى يدويًا وتشغيل انتهاء الصلاحية عليها. من غير المحتمل أن يحدث هذا تلقائيًا ، لأن النسخ المتماثل غير متزامن. على الرغم من أننا سنتشاور على الأرجح مع فريق Tarantool.
في حالة النمو الهائل للمجموعات ، يجب علينا أيضًا أن نطلب من فريق Tarantool المساعدة. الحقيقة هي أنه يتم استخدام النسخ المتماثل الكل في قائمة انتظار Tarantool وتوفير intercluster من الأحكام. يعمل هذا بشكل جيد ، على الرغم من وجود ثلاث مجموعات ، على سبيل المثال ، ولكن عندما يكون هناك 100 منها ، سيكون عدد الاتصالات التي تحتاج إلى مراقبة كبيرًا بشكل لا يصدق ، وسوف ينقطع شيء باستمرار. ثانياً ، ليست حقيقة أن Tarantool يمكنه تحمل مثل هذا الحمل.
النتائج
الاستنتاجات الأولى تتعلق UDP الإرسال المتعدد و Tarantool.
البث المتعدد لا يحتاج إلى الخوف منه ؛ استخدامه داخل المجموعة جيد وصحيح وسريع. هناك العديد من الحالات عندما يكون هناك تزامن مستمر للحالات ، وبعد 50 مللي ثانية لا يهم ما حدث من قبل. وفي هذه الحالة ، على الأرجح ، لن يكون فقدان دولة واحدة مشكلة. لذا ، فإن استخدام الإرسال المتعدد UDP له ما يبرره ، لأنك لا تحد من الأداء وتحصل على معدل الحزمة الأمثل.النقطة الثانية هي Tarantool. إذا كانت لديك خدمة قيد التنفيذ و php وما إلى ذلك ، فمن المرجح أن يكون تطبيق Tarantool قابلاً للتطبيق كما هو. ولكن إذا كان لديك حمولات ثقيلة ، فستحتاج إلى ملف. ولكن لنكون صادقين ، في هذه الحالة ، يكون الملف ضروريًا لكل شيء: بالنسبة إلى Oracle و PostgeSQL., , , , : Redis , go, python . . , , open source, , , , , . , . Tarantool, , , Redis, .