أهلاً بكم! اسمي سيرجي كوستانباييف، في البورصة أقوم بتطوير جوهر نظام التداول.
عندما تعرض أفلام هوليوود بورصة نيويورك للأوراق المالية، يبدو الأمر دائمًا على هذا النحو: حشود من الناس، الجميع يصرخون بشيء ما، ويلوحون بالأوراق، وتحدث الفوضى الكاملة. لم يحدث هذا أبدًا هنا في بورصة موسكو، لأن التداول تم إجراؤه إلكترونيًا منذ البداية ويستند إلى منصتين رئيسيتين - Spectra (سوق الفوركس) وASTS (سوق الصرف الأجنبي والأسهم والمال). واليوم أريد أن أتحدث عن تطور بنية نظام التداول والمقاصة ASTS، وعن الحلول والنتائج المختلفة. القصة ستكون طويلة لذا كان علي أن أقسمها إلى قسمين.
نحن واحدة من البورصات القليلة في العالم التي تتداول الأصول من جميع الفئات وتوفر مجموعة كاملة من خدمات الصرف. على سبيل المثال، احتلنا العام الماضي المركز الثاني على مستوى العالم من حيث حجم تداول السندات، والمركز 25 بين جميع البورصات، والمركز 13 من حيث الرسملة بين البورصات العامة.
بالنسبة للمشاركين في التداول المحترفين، تعد المعلمات مثل وقت الاستجابة واستقرار توزيع الوقت (الارتعاش) وموثوقية المجمع بأكمله أمرًا بالغ الأهمية. نقوم حاليًا بمعالجة عشرات الملايين من المعاملات يوميًا. تستغرق معالجة كل معاملة بواسطة نواة النظام عشرات الميكروثانية. بالطبع، مشغلي الهاتف المحمول في ليلة رأس السنة الجديدة أو محركات البحث أنفسهم لديهم عبء عمل أعلى من عبء العمل لدينا، ولكن من حيث عبء العمل، إلى جانب الخصائص المذكورة أعلاه، يبدو لي أن القليل منهم يمكنهم المقارنة معنا. في الوقت نفسه، من المهم بالنسبة لنا أن النظام لم يتباطأ لمدة ثانية، ويعمل بشكل مستقر تماما، وجميع المستخدمين على قدم المساواة.
قليلا من التاريخ
في عام 1994، تم إطلاق نظام ASTS الأسترالي في بورصة العملات بين البنوك في موسكو (MICEX)، ومنذ تلك اللحظة يمكن إحصاء التاريخ الروسي للتداول الإلكتروني. في عام 1998، تم تحديث بنية البورصة لتقديم التداول عبر الإنترنت. منذ ذلك الحين، أصبحت سرعة تنفيذ الحلول الجديدة والتغييرات المعمارية في جميع الأنظمة والأنظمة الفرعية تكتسب زخمًا.
في تلك السنوات، كان نظام التبادل يعمل على أجهزة متطورة - خوادم HP Superdome 9000 فائقة الموثوقية (المبنية على)، حيث تم تكرار كل شيء على الإطلاق: الأنظمة الفرعية للإدخال / الإخراج، والشبكة، وذاكرة الوصول العشوائي (في الواقع، كانت هناك مجموعة RAID من ذاكرة الوصول العشوائي)، والمعالجات (قابلة للتبديل السريع). كان من الممكن تغيير أي مكون من مكونات الخادم دون إيقاف الجهاز. لقد اعتمدنا على هذه الأجهزة واعتبرناها آمنة من الفشل تقريبًا. كان نظام التشغيل عبارة عن نظام HP UX يشبه Unix.
ولكن منذ عام 2010 تقريبًا، ظهرت ظاهرة تسمى التداول عالي التردد (HFT)، أو التداول عالي التردد - ببساطة، روبوتات البورصة. في غضون عامين ونصف فقط، زاد الحمل على خوادمنا 2,5 مرة.
كان من المستحيل تحمل مثل هذا العبء بالهندسة المعمارية والمعدات القديمة. كان من الضروري التكيف بطريقة أو بأخرى.
بداية
يمكن تقسيم الطلبات المقدمة إلى نظام الصرف إلى نوعين:
- المعاملات. إذا كنت ترغب في شراء دولارات أو أسهم أو أي شيء آخر، فإنك ترسل المعاملة إلى نظام التداول وتتلقى ردًا بشأن النجاح.
- طلبات المعلومات. إذا كنت تريد معرفة السعر الحالي، فاطلع على دفتر الطلبات أو المؤشرات، ثم أرسل طلبات المعلومات.
من الناحية التخطيطية، يمكن تقسيم جوهر النظام إلى ثلاثة مستويات:
- مستوى العميل، الذي يعمل فيه الوسطاء والعملاء. انهم جميعا يتفاعلون مع خوادم الوصول.
- خوادم البوابة عبارة عن خوادم تخزين مؤقت تقوم بمعالجة جميع طلبات المعلومات محليًا. هل تريد معرفة السعر الذي يتم تداول أسهم سبيربنك به حاليًا؟ يذهب الطلب إلى خادم الوصول.
- ولكن إذا كنت ترغب في شراء الأسهم، فإن الطلب يذهب إلى الخادم المركزي (محرك التجارة). يوجد خادم واحد لكل نوع من الأسواق، وهم يلعبون دورًا حيويًا، وقد أنشأنا هذا النظام من أجلهم.
جوهر نظام التداول هو قاعدة بيانات ذكية في الذاكرة حيث تكون جميع المعاملات عبارة عن معاملات تبادلية. تمت كتابة القاعدة بلغة C، وكانت التبعيات الخارجية الوحيدة هي مكتبة libc ولم يكن هناك تخصيص ديناميكي للذاكرة على الإطلاق. لتقليل وقت المعالجة، يبدأ النظام بمجموعة ثابتة من المصفوفات وبنقل البيانات الثابتة: أولاً، يتم تحميل جميع بيانات اليوم الحالي في الذاكرة، ولا يتم تنفيذ أي وصول إضافي إلى القرص، ويتم تنفيذ كل العمل في الذاكرة فقط. عند بدء تشغيل النظام، يتم فرز جميع البيانات المرجعية بالفعل، وبالتالي فإن البحث يعمل بكفاءة عالية ولا يستغرق سوى القليل من الوقت في وقت التشغيل. يتم إنشاء جميع الجداول باستخدام قوائم وأشجار متطفلة لهياكل البيانات الديناميكية بحيث لا تتطلب تخصيص الذاكرة في وقت التشغيل.
دعونا نلقي نظرة سريعة على تاريخ تطور نظام التداول والمقاصة لدينا.
تم بناء الإصدار الأول من بنية نظام التداول والمقاصة على ما يسمى بتفاعل يونكس: تم استخدام الذاكرة المشتركة والإشارات وقوائم الانتظار، وتتكون كل عملية من خيط واحد. وقد انتشر هذا النهج على نطاق واسع في أوائل التسعينيات.
احتوت النسخة الأولى من النظام على مستويين من البوابة وخادم مركزي لنظام التداول. وكان سير العمل مثل هذا:
- يرسل العميل طلبًا يصل إلى البوابة. فهو يتحقق من صحة التنسيق (ولكن ليس البيانات نفسها) ويرفض المعاملات غير الصحيحة.
- إذا تم إرسال طلب معلومات، فسيتم تنفيذه محليًا؛ إذا كنا نتحدث عن معاملة، فسيتم إعادة توجيهها إلى الخادم المركزي.
- يقوم محرك التداول بعد ذلك بمعالجة المعاملة وتعديل الذاكرة المحلية وإرسال استجابة للمعاملة والمعاملة نفسها للنسخ المتماثل باستخدام محرك نسخ منفصل.
- تتلقى البوابة الاستجابة من العقدة المركزية وترسلها إلى العميل.
- بعد مرور بعض الوقت، تتلقى البوابة المعاملة من خلال آلية النسخ المتماثل، وهذه المرة تقوم بتنفيذها محليًا، وتغيير هياكل البيانات الخاصة بها بحيث تعرض طلبات المعلومات التالية أحدث البيانات.
في الواقع، ما تم وصفه هنا هو نموذج النسخ المتماثل حيث تقوم البوابة بتكرار الإجراءات التي يتم تنفيذها في نظام التداول بشكل كامل. تضمن قناة النسخ المتماثل المنفصلة تنفيذ المعاملات بنفس الترتيب عبر عقد وصول متعددة.
نظرًا لأن الكود كان أحادي الترابط، فقد تم استخدام مخطط كلاسيكي مع شوكات العملية لخدمة العديد من العملاء. ومع ذلك، كان تفرع قاعدة البيانات بأكملها مكلفًا للغاية، لذلك تم استخدام عمليات خدمة خفيفة الوزن لجمع الحزم من جلسات TCP ونقلها إلى قائمة انتظار واحدة (قائمة انتظار الرسائل SystemV). تعمل البوابة وTrade Engine فقط مع قائمة الانتظار هذه، حيث تأخذ المعاملات من هناك للتنفيذ. ولم يعد من الممكن إرسال رد عليه، لأنه لم يكن من الواضح أي عملية خدمة يجب أن تقرأه. لذلك لجأنا إلى خدعة: كل عملية متشعبة تنشئ قائمة انتظار استجابة لنفسها، وعندما يأتي طلب إلى قائمة الانتظار الواردة، تتم إضافة علامة لقائمة انتظار الاستجابة إليها على الفور.
أدى النسخ المستمر لكميات كبيرة من البيانات من قائمة انتظار إلى أخرى إلى ظهور مشكلات، خاصة بالنسبة لطلبات المعلومات. لذلك، استخدمنا خدعة أخرى: بالإضافة إلى قائمة انتظار الاستجابة، تقوم كل عملية أيضًا بإنشاء ذاكرة مشتركة (SystemV Shared Memory). تم وضع الحزم نفسها فيه، وتم تخزين علامة فقط في قائمة الانتظار، مما يسمح للشخص بالعثور على الحزمة الأصلية. وقد ساعد هذا في تخزين البيانات في ذاكرة التخزين المؤقت للمعالج.
يتضمن SystemV IPC أدوات مساعدة لعرض حالة قائمة الانتظار والذاكرة وكائنات الإشارة. لقد استخدمنا هذا بشكل فعال لفهم ما كان يحدث في النظام في لحظة معينة، حيث تراكمت الحزم، وما تم حظره، وما إلى ذلك.
الترقيات الأولى
بادئ ذي بدء، تخلصنا من بوابة العملية الواحدة. كان عيبه الكبير هو أنه يمكنه التعامل مع معاملة نسخ متماثل واحدة أو طلب معلومات واحد من العميل. ومع زيادة التحميل، ستستغرق البوابة وقتًا أطول لمعالجة الطلبات ولن تكون قادرة على معالجة تدفق النسخ المتماثل. بالإضافة إلى ذلك، إذا أرسل العميل معاملة، فأنت تحتاج فقط إلى التحقق من صحتها وإعادة توجيهها أكثر. لذلك، استبدلنا عملية البوابة الواحدة بمكونات متعددة يمكن تشغيلها بالتوازي: معلومات متعددة الخيوط وعمليات معاملات تعمل بشكل مستقل عن بعضها البعض في منطقة ذاكرة مشتركة باستخدام قفل RW. وفي الوقت نفسه قدمنا عمليات الإرسال والنسخ.
تأثير التداول عالي التردد
الإصدار أعلاه من البنية موجود حتى عام 2010. وفي الوقت نفسه، لم نعد راضين عن أداء خوادم HP Superdome. بالإضافة إلى ذلك، كانت بنية PA-RISC ميتة تقريبًا؛ ولم يقدم البائع أي تحديثات مهمة. ونتيجة لذلك، بدأنا في الانتقال من HP UX/PA RISC إلى Linux/x86. بدأ التحول بتكييف خوادم الوصول.
لماذا كان علينا تغيير الهندسة المعمارية مرة أخرى؟ الحقيقة هي أن التداول عالي التردد قد غيّر بشكل كبير ملف تعريف الحمل على قلب النظام.
لنفترض أن لدينا معاملة صغيرة تسببت في تغيير كبير في السعر - اشترى شخص ما نصف مليار دولار. وبعد بضعة أجزاء من الثانية، لاحظ جميع المشاركين في السوق ذلك وبدأوا في إجراء التصحيح. وبطبيعة الحال، تصطف الطلبات في قائمة انتظار ضخمة، وسيستغرق النظام وقتًا طويلاً لمسحها.
في هذه الفترة الزمنية البالغة 50 مللي ثانية، يبلغ متوسط السرعة حوالي 16 ألف معاملة في الثانية. إذا قمنا بتقليل النافذة إلى 20 مللي ثانية، فسنحصل على متوسط سرعة 90 ألف معاملة في الثانية، مع 200 ألف معاملة في الذروة. وبعبارة أخرى، فإن الحمل ليس ثابتا، مع رشقات نارية مفاجئة. ويجب دائمًا معالجة قائمة انتظار الطلبات بسرعة.
ولكن لماذا يوجد طابور على الإطلاق؟ لذلك، في مثالنا، لاحظ العديد من المستخدمين تغير السعر وأرسلوا المعاملات وفقًا لذلك. يأتون إلى Gateway، ويقوم بتسلسلهم، ويضع ترتيبًا معينًا ويرسلهم إلى الشبكة. تقوم أجهزة التوجيه بخلط الحزم وإعادة توجيهها. من وصل طرده أولاً، "فازت" تلك الصفقة. ونتيجة لذلك، بدأ عملاء البورصة يلاحظون أنه إذا تم إرسال نفس المعاملة من عدة بوابات، فإن فرص معالجتها السريعة تزداد. وسرعان ما بدأت روبوتات البورصة في قصف البوابة بالطلبات، ونشأ سيل من المعاملات.
جولة جديدة من التطور
بعد إجراء اختبارات وأبحاث مكثفة، تحولنا إلى نواة نظام التشغيل في الوقت الفعلي. ولهذا اخترنا RedHat Enterprise MRG Linux، حيث يرمز MRG إلى شبكة المراسلة في الوقت الفعلي. تتمثل ميزة التصحيحات في الوقت الفعلي في أنها تعمل على تحسين النظام لتحقيق أسرع تنفيذ ممكن: يتم اصطفاف جميع العمليات في قائمة انتظار FIFO، ويمكن عزل النوى، وعدم وجود عمليات إخراج، وتتم معالجة جميع المعاملات بتسلسل صارم.
الأحمر - العمل مع قائمة الانتظار في نواة عادية، والأخضر - العمل في نواة في الوقت الحقيقي.
لكن تحقيق زمن استجابة منخفض على الخوادم العادية ليس بالأمر السهل:
- يتداخل وضع SMI بشكل كبير، والذي يعد في بنية x86 أساسًا للعمل مع الأجهزة الطرفية المهمة. تتم معالجة جميع أنواع أحداث الأجهزة وإدارة المكونات والأجهزة بواسطة البرامج الثابتة في ما يسمى بوضع SMI الشفاف، حيث لا يرى نظام التشغيل ما تفعله البرامج الثابتة على الإطلاق. كقاعدة عامة، يقدم جميع البائعين الرئيسيين امتدادات خاصة لخوادم البرامج الثابتة التي تسمح بتقليل كمية معالجة SMI.
- لا ينبغي أن يكون هناك تحكم ديناميكي في تردد المعالج، وهذا يؤدي إلى توقف إضافي.
- عندما يتم مسح سجل نظام الملفات، تحدث عمليات معينة في النواة والتي تسبب تأخيرات غير متوقعة.
- أنت بحاجة إلى الانتباه إلى أشياء مثل تقارب وحدة المعالجة المركزية (CPU) وتقارب المقاطعة وNUMA.
يجب أن أقول إن موضوع إعداد أجهزة ونواة Linux للمعالجة في الوقت الفعلي يستحق مقالًا منفصلاً. لقد أمضينا الكثير من الوقت في التجربة والبحث قبل أن نحقق نتيجة جيدة.
عند الانتقال من خوادم PA-RISC إلى x86، لم نضطر عمليًا إلى تغيير رمز النظام كثيرًا، لقد قمنا فقط بتكييفه وإعادة تكوينه. وفي الوقت نفسه، قمنا بإصلاح العديد من الأخطاء. على سبيل المثال، ظهرت بسرعة عواقب حقيقة أن PA RISC كان نظامًا endian كبيرًا، وأن x86 كان نظامًا endian صغيرًا: على سبيل المثال، تمت قراءة البيانات بشكل غير صحيح. كان الخطأ الأكثر صعوبة هو أن PA RISC يستخدم () الوصول إلى الذاكرة، بينما يمكن لـ x86 إعادة ترتيب عمليات القراءة، وبالتالي فإن التعليمات البرمجية التي كانت صالحة تمامًا على أحد الأنظمة الأساسية أصبحت معطلة على نظام آخر.
بعد التبديل إلى x86، زاد الأداء ثلاثة أضعاف تقريبًا، وانخفض متوسط وقت معالجة المعاملة إلى 60 ميكروثانية.
دعونا الآن نلقي نظرة فاحصة على التغييرات الرئيسية التي تم إجراؤها على بنية النظام.
ملحمة الاحتياطي الساخنة
عند التحول إلى خوادم السلع الأساسية، كنا ندرك أنها أقل موثوقية. لذلك، عند إنشاء بنية جديدة، افترضنا مسبقًا إمكانية فشل عقدة واحدة أو أكثر. لذلك، كانت هناك حاجة إلى نظام احتياطي سريع يمكنه التحول بسرعة كبيرة إلى أجهزة النسخ الاحتياطي.
وبالإضافة إلى ذلك، كانت هناك متطلبات أخرى:
- لا يجب أن تفقد المعاملات التي تمت معالجتها تحت أي ظرف من الظروف.
- يجب أن يكون النظام شفافًا تمامًا بالنسبة لبنيتنا التحتية.
- يجب ألا يرى العملاء الاتصالات المسقطة.
- لا ينبغي أن تؤدي التحفظات إلى تأخير كبير لأن هذا عامل حاسم للتبادل.
عند إنشاء نظام الاستعداد السريع، لم نعتبر مثل هذه السيناريوهات كفشل مزدوج (على سبيل المثال، توقفت الشبكة على خادم واحد عن العمل وتجمد الخادم الرئيسي)؛ لم يأخذ في الاعتبار إمكانية وجود أخطاء في البرنامج لأنه يتم تحديدها أثناء الاختبار؛ ولم تنظر في التشغيل غير الصحيح للأجهزة.
ونتيجة لذلك وصلنا إلى المخطط التالي:
- تفاعل الخادم الرئيسي مباشرة مع خوادم البوابة.
- تم نسخ جميع المعاملات المستلمة على الخادم الرئيسي على الفور إلى الخادم الاحتياطي عبر قناة منفصلة. يقوم الحكم (الحاكم) بتنسيق عملية التبديل في حالة ظهور أي مشاكل.
- قام الخادم الرئيسي بمعالجة كل معاملة وانتظر التأكيد من خادم النسخ الاحتياطي. وللحفاظ على زمن الوصول إلى الحد الأدنى، تجنبنا انتظار اكتمال المعاملة على خادم النسخ الاحتياطي. نظرًا لأن الوقت الذي تستغرقه المعاملة للانتقال عبر الشبكة كان مشابهًا لوقت التنفيذ، لم تتم إضافة أي زمن وصول إضافي.
- لم نتمكن إلا من التحقق من حالة معالجة الخوادم الرئيسية والاحتياطية للمعاملة السابقة، وكانت حالة معالجة المعاملة الحالية غير معروفة. وبما أننا لا نزال نستخدم عمليات ذات ترابط واحد، فإن انتظار الرد من النسخ الاحتياطي قد يؤدي إلى إبطاء تدفق المعالجة بالكامل، لذلك قمنا بتسوية معقولة: لقد تحققنا من نتيجة المعاملة السابقة.
عملت المخطط على النحو التالي.
لنفترض أن الخادم الرئيسي توقف عن الاستجابة، لكن البوابات تستمر في الاتصال. تنتهي المهلة على الخادم الاحتياطي، ويتصل بالحاكم، الذي يعينه دور الخادم الرئيسي، وتتحول جميع البوابات إلى الخادم الرئيسي الجديد.
إذا عاد الخادم الرئيسي متصلاً بالإنترنت مرة أخرى، فسيؤدي ذلك أيضًا إلى تشغيل مهلة داخلية، لأنه لم تكن هناك مكالمات إلى الخادم من البوابة لفترة معينة. ثم يلجأ هو الآخر إلى الوالي فيستبعده من المخطط. ونتيجة لذلك، تعمل البورصة مع خادم واحد حتى نهاية فترة التداول. نظرًا لأن احتمال فشل الخادم منخفض جدًا، فقد تم اعتبار هذا المخطط مقبولًا تمامًا، ولم يحتوي على منطق معقد وكان من السهل اختباره.
أن تستمر.
المصدر: www.habr.com