هذا استمرار لقصة طويلة حول طريقنا الشائك لإنشاء نظام قوي وعالي التحميل يضمن تشغيل البورصة. الجزء الأول هنا:
خطأ غامض
بعد العديد من الاختبارات، تم تشغيل نظام التداول والمقاصة المحدث، وواجهنا خطأ يمكننا كتابة قصة بوليسية غامضة عنه.
بعد وقت قصير من التشغيل على الخادم الرئيسي، تمت معالجة إحدى المعاملات مع حدوث خطأ. ومع ذلك، كان كل شيء على ما يرام على خادم النسخ الاحتياطي. اتضح أن عملية حسابية بسيطة لحساب الأس على الخادم الرئيسي أعطت نتيجة سلبية من الوسيطة الحقيقية! واصلنا بحثنا، وفي سجل SSE2 وجدنا اختلافًا في بت واحد، وهو المسؤول عن التقريب عند العمل مع أرقام الفاصلة العائمة.
لقد كتبنا أداة اختبار بسيطة لحساب الأس باستخدام مجموعة بتات التقريب. اتضح أنه في إصدار RedHat Linux الذي استخدمناه، كان هناك خطأ في العمل مع الوظيفة الرياضية عندما تم إدراج البت المشؤوم. لقد أبلغنا RedHat بهذا، وبعد فترة تلقينا تصحيحًا منهم وقمنا بطرحه. لم يعد الخطأ يحدث، ولكن لم يكن من الواضح من أين جاء هذا الشيء؟ وكانت الوظيفة مسؤولة عن ذلك fesetround من لغة C. قمنا بتحليل الكود الخاص بنا بعناية بحثًا عن الخطأ المفترض: لقد فحصنا جميع المواقف المحتملة؛ نظرت إلى جميع الوظائف التي تستخدم التقريب؛ حاول إعادة إنتاج جلسة فاشلة؛ استخدام مترجمين مختلفين مع خيارات مختلفة؛ تم استخدام التحليل الثابت والديناميكي.
لا يمكن العثور على سبب الخطأ.
ثم بدأوا في فحص الأجهزة: لقد أجروا اختبار تحميل المعالجات؛ فحص ذاكرة الوصول العشوائي. لقد أجرينا أيضًا اختبارات للسيناريو غير المحتمل جدًا لحدوث خطأ متعدد البتات في خلية واحدة. ولكن دون جدوى.
في النهاية، استقرينا على نظرية من عالم فيزياء الطاقة العالية: طارت بعض الجسيمات عالية الطاقة إلى مركز البيانات لدينا، واخترقت جدار العلبة، واصطدمت بالمعالج وتسببت في التصاق مزلاج الزناد في تلك القطعة بالذات. هذه النظرية السخيفة كانت تسمى "النيوترينو". إذا كنت بعيدًا عن فيزياء الجسيمات: فالنيوترينوات لا تتفاعل تقريبًا مع العالم الخارجي، وهي بالتأكيد غير قادرة على التأثير على عمل المعالج.
نظرًا لعدم إمكانية العثور على سبب الفشل، تمت إزالة الخادم "المخالف" من التشغيل تحسبًا لذلك.
بعد مرور بعض الوقت، بدأنا في تحسين نظام النسخ الاحتياطي الساخن: قدمنا ما يسمى "الاحتياطيات الدافئة" (الدافئة) - النسخ المتماثلة غير المتزامنة. لقد تلقوا دفقًا من المعاملات التي يمكن أن تكون موجودة في مراكز بيانات مختلفة، لكن الدفء لم يتفاعل بشكل نشط مع الخوادم الأخرى.
لماذا تم ذلك؟ إذا فشل خادم النسخ الاحتياطي، فإن الارتباط الدافئ بالخادم الرئيسي يصبح هو النسخة الاحتياطية الجديدة. أي أنه بعد حدوث فشل، لا يبقى النظام مع خادم رئيسي واحد حتى نهاية جلسة التداول.
وعندما تم اختبار الإصدار الجديد من النظام وتشغيله، حدث خطأ بت التقريب مرة أخرى. علاوة على ذلك، مع زيادة عدد الخوادم الدافئة، بدأ الخطأ في الظهور في كثير من الأحيان. وفي الوقت نفسه، لم يكن لدى البائع ما يظهره، لأنه لم يكن هناك دليل ملموس.
أثناء التحليل التالي للموقف، ظهرت نظرية مفادها أن المشكلة قد تكون مرتبطة بنظام التشغيل. لقد كتبنا برنامجًا بسيطًا يستدعي دالة في حلقة لا نهاية لها fesetround، يتذكر الحالة الحالية ويتحقق منها من خلال النوم، ويتم ذلك في العديد من المواضيع المتنافسة. بعد تحديد معلمات وضع السكون وعدد الخيوط، بدأنا في إعادة إنتاج فشل البت باستمرار بعد حوالي 5 دقائق من تشغيل الأداة المساعدة. ومع ذلك، لم يتمكن دعم Red Hat من إعادة إنتاجه. أظهر اختبار خوادمنا الأخرى أن الخوادم التي لديها معالجات معينة فقط هي المعرضة للخطأ. وفي الوقت نفسه، أدى التحول إلى نواة جديدة إلى حل المشكلة. في النهاية، قمنا ببساطة باستبدال نظام التشغيل، وظل السبب الحقيقي للخلل غير واضح.
وفجأة نُشر في العام الماضي مقال عن حبري “" كان الموقف الموصوف فيه مشابهًا جدًا لحالتنا، لكن المؤلف أخذ التحقيق أبعد وطرح نظرية مفادها أن الخطأ كان في الرمز الصغير. وعندما يتم تحديث نواة Linux، تقوم الشركات المصنعة أيضًا بتحديث الرمز الصغير.
مواصلة تطوير النظام
وعلى الرغم من أننا تخلصنا من الخطأ، إلا أن هذه القصة أجبرتنا على إعادة النظر في بنية النظام. بعد كل شيء، لم نكن محميين من تكرار مثل هذه الأخطاء.
شكلت المبادئ التالية الأساس للتحسينات التالية لنظام الحجز:
- لا يمكنك الوثوق بأي شخص. قد لا تعمل الخوادم بشكل صحيح.
- حجز الأغلبية.
- ضمان الإجماع. كإضافة منطقية لحجز الأغلبية.
- الفشل المزدوج ممكن.
- حيوية. يجب ألا يكون نظام الاستعداد الساخن الجديد أسوأ من النظام السابق. يجب أن يستمر التداول دون انقطاع حتى آخر خادم.
- زيادة طفيفة في الكمون. أي توقف ينطوي على خسائر مالية فادحة.
- الحد الأدنى من تفاعل الشبكة للحفاظ على زمن الوصول عند أدنى مستوى ممكن.
- اختيار خادم رئيسي جديد في ثواني.
لم يناسبنا أي من الحلول المتوفرة في السوق، وكان بروتوكول Raft لا يزال في بداياته، لذلك أنشأنا الحل الخاص بنا.
الشبكات
بالإضافة إلى نظام الحجز، بدأنا في تحديث تفاعل الشبكة. يتكون نظام الإدخال/الإخراج الفرعي من العديد من العمليات، والتي كان لها أسوأ الأثر على الارتعاش وزمن الوصول. مع مئات العمليات التي تتعامل مع اتصالات TCP، اضطررنا إلى التبديل بينها باستمرار، وعلى نطاق ميكروثانية، تعد هذه عملية تستغرق وقتًا طويلاً إلى حد ما. لكن أسوأ ما في الأمر هو أنه عندما تتلقى عملية ما حزمة للمعالجة، فإنها ترسلها إلى قائمة انتظار SystemV واحدة ثم تنتظر حدثًا من قائمة انتظار SystemV أخرى. ومع ذلك، عندما يكون هناك عدد كبير من العقد، فإن وصول حزمة TCP جديدة في إحدى العمليات واستلام البيانات في قائمة الانتظار في عملية أخرى يمثلان حدثين متنافسين لنظام التشغيل. في هذه الحالة، إذا لم تكن هناك معالجات فعلية متاحة لكلا المهمتين، فستتم معالجة إحداهما، وسيتم وضع الثانية في قائمة انتظار الانتظار. ومن المستحيل التنبؤ بالعواقب.
في مثل هذه الحالات، يمكن استخدام التحكم الديناميكي في أولوية العملية، ولكن هذا سيتطلب استخدام مكالمات النظام كثيفة الاستخدام للموارد. ونتيجة لذلك، قمنا بالتبديل إلى مؤشر ترابط واحد باستخدام epoll الكلاسيكي، مما أدى إلى زيادة السرعة بشكل كبير وتقليل وقت معالجة المعاملة. لقد تخلصنا أيضًا من عمليات الاتصال المنفصلة بالشبكة والتواصل من خلال SystemV، وقللنا بشكل كبير عدد مكالمات النظام وبدأنا في التحكم في أولويات العمليات. في نظام الإدخال/الإخراج الفرعي وحده، كان من الممكن توفير حوالي 8-17 ميكروثانية، اعتمادًا على السيناريو. تم استخدام هذا المخطط أحادي الترابط دون تغيير منذ ذلك الحين؛ يكفي خيط epoll واحد بهامش لخدمة جميع الاتصالات.
معالجة المعاملات
يتطلب الحمل المتزايد على نظامنا ترقية جميع مكوناته تقريبًا. ولكن لسوء الحظ، فإن الركود في نمو سرعات ساعة المعالج في السنوات الأخيرة لم يعد من الممكن توسيع نطاق العمليات بشكل مباشر. لذلك، قررنا تقسيم عملية المحرك إلى ثلاثة مستويات، أكثرها ازدحامًا هو نظام فحص المخاطر، الذي يقيم مدى توفر الأموال في الحسابات وينشئ المعاملات نفسها. ولكن يمكن أن تكون الأموال بعملات مختلفة، وكان من الضروري معرفة على أي أساس ينبغي تقسيم معالجة الطلبات.
الحل المنطقي هو تقسيمها حسب العملة: خادم واحد يتداول بالدولار، وآخر بالجنيه، وثالث باليورو. ولكن إذا تم إرسال معاملتين، باستخدام مثل هذا المخطط، لشراء عملات مختلفة، فستنشأ مشكلة إلغاء مزامنة المحفظة. لكن المزامنة صعبة ومكلفة. لذلك، سيكون من الصحيح تقسيمها بشكل منفصل عن طريق المحافظ وبشكل منفصل عن طريق الأدوات. بالمناسبة، لا تتولى معظم البورصات الغربية مهمة التحقق من المخاطر بنفس القدر من الدقة الذي نقوم به، لذلك يتم ذلك في أغلب الأحيان دون اتصال بالإنترنت. كنا بحاجة إلى تنفيذ التحقق عبر الإنترنت.
دعونا نشرح مع مثال. يريد المتداول شراء 30 دولارًا، وينتقل الطلب إلى التحقق من صحة المعاملة: نتحقق مما إذا كان هذا المتداول مسموحًا له بوضع التداول هذا وما إذا كان لديه الحقوق اللازمة. إذا كان كل شيء على ما يرام، يذهب الطلب إلى نظام التحقق من المخاطر، أي. للتحقق من كفاية الأموال لإبرام الصفقة. هناك ملاحظة أن المبلغ المطلوب محجوب حاليا. يتم بعد ذلك تحويل الطلب إلى نظام التداول، الذي يوافق على المعاملة أو يرفضها. لنفترض أنه تمت الموافقة على المعاملة - ثم يشير نظام التحقق من المخاطر إلى أن الأموال غير محظورة، وأن الروبل يتحول إلى دولارات.
بشكل عام، يحتوي نظام فحص المخاطر على خوارزميات معقدة ويقوم بعدد كبير من العمليات الحسابية كثيفة الاستخدام للموارد، ولا يقوم ببساطة بالتحقق من "رصيد الحساب"، كما قد يبدو للوهلة الأولى.
عندما بدأنا بتقسيم عملية المحرك إلى مستويات، واجهنا مشكلة: الكود الذي كان متاحًا في ذلك الوقت استخدم بشكل فعال نفس مجموعة البيانات في مرحلتي التحقق والتحقق، الأمر الذي يتطلب إعادة كتابة قاعدة التعليمات البرمجية بأكملها. ونتيجة لذلك، استعرنا تقنية معالجة التعليمات من المعالجات الحديثة: كل منها مقسم إلى مراحل صغيرة ويتم تنفيذ العديد من الإجراءات بالتوازي في دورة واحدة.
بعد تعديل بسيط للكود، أنشأنا مسارًا لمعالجة المعاملات المتوازية، حيث تم تقسيم المعاملة إلى 4 مراحل من المسار: تفاعل الشبكة والتحقق من الصحة والتنفيذ ونشر النتيجة
لنلقي نظرة على مثال. لدينا نظامين للمعالجة، تسلسلي ومتوازي. وصول المعاملة الأولى وإرسالها للتحقق من صحتها في كلا النظامين. تصل المعاملة الثانية على الفور: في النظام الموازي يتم تشغيلها على الفور، وفي النظام التسلسلي يتم وضعها في قائمة الانتظار في انتظار مرور المعاملة الأولى بمرحلة المعالجة الحالية. أي أن الميزة الرئيسية لمعالجة خطوط الأنابيب هي أننا نقوم بمعالجة قائمة انتظار المعاملات بشكل أسرع.
هذه هي الطريقة التي توصلنا بها إلى نظام ASTS+.
صحيح، ليس كل شيء سلسًا جدًا مع الناقلات أيضًا. لنفترض أن لدينا معاملة تؤثر على صفائف البيانات في معاملة مجاورة؛ وهذا هو الوضع النموذجي للتبادل. لا يمكن تنفيذ مثل هذه المعاملة في خط أنابيب لأنها قد تؤثر على الآخرين. يُطلق على هذا الموقف اسم خطر البيانات، وتتم معالجة مثل هذه المعاملات بشكل منفصل: عندما تنفد المعاملات "السريعة" في قائمة الانتظار، يتوقف خط الأنابيب، ويقوم النظام بمعالجة المعاملة "البطيئة"، ثم يبدأ خط الأنابيب مرة أخرى. ولحسن الحظ، فإن نسبة مثل هذه المعاملات في التدفق الإجمالي صغيرة جدًا، لذا نادرًا ما يتوقف خط الأنابيب بحيث لا يؤثر ذلك على الأداء العام.
ثم بدأنا في حل مشكلة مزامنة خيوط التنفيذ الثلاثة. وكانت النتيجة نظامًا يعتمد على المخزن المؤقت الحلقي ذي الخلايا ذات الحجم الثابت. في هذا النظام، كل شيء يخضع لسرعة المعالجة، ولا يتم نسخ البيانات.
- تدخل جميع حزم الشبكة الواردة إلى مرحلة التخصيص.
- نضعهم في مصفوفة ونضع علامة عليها كمتاحة للمرحلة رقم 1.
- وصلت الصفقة الثانية، وهي متاحة مرة أخرى للمرحلة رقم 1.
- يرى خيط المعالجة الأول المعاملات المتاحة ويعالجها وينقلها إلى المرحلة التالية من خيط المعالجة الثاني.
- ثم يقوم بمعالجة المعاملة الأولى ووضع علامة على الخلية المقابلة
deleted- إنه متاح الآن للاستخدام الجديد.
تتم معالجة قائمة الانتظار بأكملها بهذه الطريقة.
تستغرق معالجة كل مرحلة وحدات أو عشرات الميكروثانية. وإذا استخدمنا أنظمة مزامنة نظام التشغيل القياسية، فسنفقد المزيد من الوقت في المزامنة نفسها. لهذا السبب بدأنا باستخدام Spinlock. ومع ذلك، يعد هذا نموذجًا سيئًا للغاية في نظام الوقت الفعلي، ولا توصي RedHat بصرامة بالقيام بذلك، لذلك نطبق قفل الدوران لمدة 100 مللي ثانية، ثم ننتقل إلى وضع الإشارة للتخلص من احتمال حدوث حالة توقف تام.
ونتيجة لذلك، حققنا أداء حوالي 8 ملايين معاملة في الثانية. وبعد شهرين حرفيًا فيما يتعلق بـ LMAX Disruptor، رأينا وصفًا لدائرة بنفس الوظيفة.
الآن يمكن أن يكون هناك عدة خيوط للتنفيذ في مرحلة واحدة. تمت معالجة جميع المعاملات واحدة تلو الأخرى، بالترتيب الذي تم استلامها به. ونتيجة لذلك، ارتفع الأداء الأقصى من 18 ألفًا إلى 50 ألف معاملة في الثانية.
نظام إدارة مخاطر الصرف
ليس هناك حد للكمال، وسرعان ما بدأنا التحديث مرة أخرى: في إطار ASTS+، بدأنا في نقل أنظمة إدارة المخاطر وعمليات التسوية إلى مكونات مستقلة. لقد قمنا بتطوير بنية حديثة مرنة ونموذج مخاطر هرمي جديد، وحاولنا استخدام الفصل حيثما أمكن ذلك fixed_point بدلا من double.
ولكن ظهرت مشكلة على الفور: كيفية مزامنة منطق العمل بأكمله الذي كان يعمل لسنوات عديدة ونقله إلى النظام الجديد؟ ونتيجة لذلك، كان لا بد من التخلي عن النسخة الأولى من النموذج الأولي للنظام الجديد. الإصدار الثاني، الذي يعمل حاليًا في مرحلة الإنتاج، يعتمد على نفس الكود، والذي يعمل في كل من قسمي التداول والمخاطرة. أثناء التطوير، كان أصعب شيء يجب القيام به هو دمج git بين نسختين. أجرى زميلنا إيفجيني مازورينوك هذه العملية كل أسبوع وفي كل مرة كان يسب لفترة طويلة جدًا.
عند اختيار نظام جديد، كان علينا على الفور حل مشكلة التفاعل. عند اختيار ناقل البيانات، كان من الضروري ضمان ارتعاش مستقر والحد الأدنى من الكمون. كانت شبكة InfiniBand RDMA هي الأنسب لهذا: متوسط وقت المعالجة أقل بأربع مرات من شبكات 4G Ethernet. ولكن ما أذهلنا حقًا هو الفرق في النسب المئوية - 10 و99.
بالطبع، لدى InfiniBand تحدياته. أولاً، واجهة برمجة تطبيقات مختلفة - ibverbs بدلاً من المقابس. ثانيًا، لا توجد تقريبًا حلول مراسلة مفتوحة المصدر متاحة على نطاق واسع. لقد حاولنا إنشاء نموذج أولي خاص بنا، ولكن تبين أن الأمر صعب للغاية، لذلك اخترنا الحل التجاري - Confinity Low Latency Messaging (المعروف سابقًا باسم IBM MQ LLM).
ثم نشأت مهمة تقسيم نظام المخاطر بشكل صحيح. إذا قمت ببساطة بإزالة محرك المخاطر ولم تقم بإنشاء عقدة وسيطة، فيمكن خلط المعاملات من مصدرين.
تتمتع ما يسمى بحلول Ultra Low Latency بوضع إعادة الطلب: يمكن ترتيب المعاملات من مصدرين بالترتيب المطلوب عند الاستلام؛ ويتم تنفيذ ذلك باستخدام قناة منفصلة لتبادل المعلومات حول الطلب. لكننا لا نستخدم هذا الوضع بعد: فهو يعقد العملية برمتها، وفي عدد من الحلول غير مدعوم على الإطلاق. بالإضافة إلى ذلك، يجب تعيين طوابع زمنية مقابلة لكل معاملة، وفي مخططنا، يصعب جدًا تنفيذ هذه الآلية بشكل صحيح. لذلك، استخدمنا المخطط الكلاسيكي مع وسيط الرسائل، أي مع مرسل يقوم بتوزيع الرسائل بين محرك المخاطر.
المشكلة الثانية تتعلق بوصول العميل: إذا كان هناك العديد من بوابات المخاطر، فسيحتاج العميل إلى الاتصال بكل منها، وسيتطلب ذلك إجراء تغييرات على طبقة العميل. أردنا الابتعاد عن هذا في هذه المرحلة، لذا فإن تصميم بوابة المخاطر الحالي يعالج تدفق البيانات بالكامل. وهذا يحد بشكل كبير من الحد الأقصى للإنتاجية، ولكنه يبسط إلى حد كبير تكامل النظام.
الازدواجية
يجب ألا يحتوي نظامنا على نقطة فشل واحدة، أي أنه يجب تكرار جميع المكونات، بما في ذلك وسيط الرسائل. لقد قمنا بحل هذه المشكلة باستخدام نظام CLLM: فهو يحتوي على مجموعة RCMS حيث يمكن لمرسلين أن يعملا في الوضع الرئيسي والتابع، وعندما يفشل أحدهما، يتحول النظام تلقائيًا إلى الآخر.
العمل مع مركز البيانات الاحتياطية
تم تحسين InfiniBand للعمل كشبكة محلية، أي لتوصيل الأجهزة المثبتة على حامل، ولا يمكن وضع شبكة InfiniBand بين مركزي بيانات موزعين جغرافيًا. ولذلك، قمنا بتنفيذ جسر/مرسل، يتصل بمخزن الرسائل عبر شبكات إيثرنت عادية وينقل جميع المعاملات إلى شبكة IB ثانية. عندما نحتاج إلى الترحيل من مركز بيانات، يمكننا اختيار مركز البيانات الذي سنعمل معه الآن.
نتائج
لم يتم تنفيذ كل ما سبق مرة واحدة، بل استغرق الأمر عدة تكرارات لتطوير بنية جديدة. لقد أنشأنا النموذج الأولي في شهر واحد، لكن الأمر استغرق أكثر من عامين حتى يصبح في حالة صالحة للعمل. لقد حاولنا تحقيق أفضل حل وسط بين زيادة وقت معالجة المعاملات وزيادة موثوقية النظام.
منذ أن تم تحديث النظام بشكل كبير، قمنا بتنفيذ استعادة البيانات من مصدرين مستقلين. إذا كان مخزن الرسائل لا يعمل بشكل صحيح لسبب ما، فيمكنك الحصول على سجل المعاملات من مصدر ثانٍ - من محرك المخاطر. يتم ملاحظة هذا المبدأ في جميع أنحاء النظام.
ومن بين أمور أخرى، تمكنا من الحفاظ على واجهة برمجة تطبيقات العميل بحيث لا يحتاج الوسطاء أو أي شخص آخر إلى إعادة صياغة كبيرة للبنية الجديدة. كان علينا تغيير بعض الواجهات، ولكن لم تكن هناك حاجة لإجراء تغييرات كبيرة على نموذج التشغيل.
أطلقنا على الإصدار الحالي من منصتنا اسم Rebus - كاختصار لاثنين من الابتكارات الأكثر شهرة في الهندسة المعمارية، وهما Risk Engine وBUS.
في البداية، أردنا تخصيص جزء المقاصة فقط، ولكن النتيجة كانت نظامًا موزعًا ضخمًا. يمكن للعملاء الآن التفاعل مع بوابة التجارة أو بوابة المقاصة أو كليهما.
ما حققناه في نهاية المطاف:
خفض مستوى الكمون. مع حجم صغير من المعاملات، يعمل النظام بنفس الطريقة التي يعمل بها الإصدار السابق، ولكن في نفس الوقت يمكنه تحمل حمل أعلى بكثير.
وزاد أداء الذروة من 50 ألفاً إلى 180 ألف معاملة في الثانية. يتم إعاقة الزيادة الإضافية من خلال الدفق الوحيد لمطابقة الطلب.
هناك طريقتان لمزيد من التحسين: موازنة المطابقة وتغيير طريقة عملها مع البوابة. الآن تعمل كافة البوابات وفقًا لنظام النسخ المتماثل، والذي، تحت مثل هذا الحمل، يتوقف عن العمل بشكل طبيعي.
أخيرًا، يمكنني تقديم بعض النصائح لأولئك الذين يقومون بوضع اللمسات الأخيرة على أنظمة المؤسسة:
- كن مستعدًا للأسوأ في جميع الأوقات. تنشأ المشاكل دائما بشكل غير متوقع.
- عادة ما يكون من المستحيل إعادة تشكيل الهندسة المعمارية بسرعة. خاصة إذا كنت بحاجة إلى تحقيق أقصى قدر من الموثوقية عبر مؤشرات متعددة. كلما زاد عدد العقد، زادت الموارد اللازمة للدعم.
- ستتطلب جميع الحلول المخصصة والمملوكة موارد إضافية للبحث والدعم والصيانة.
- لا تؤجل حل المشكلات المتعلقة بموثوقية النظام واسترداده بعد الأعطال، بل ضعها في الاعتبار في مرحلة التصميم الأولية.
المصدر: www.habr.com