دفتر الأوامر يتجمّد حين تزدحم السوق؟ كيف تُصلح تغذية بيانات السوق ومن يستطيع ذلك

إذا كان دفتر الأوامر على شاشات التداول لديك يتجمّد أو يقفز أو يعرض أسعارًا مستحيلة حين تزدحم السوق، فالعيب يقع عادةً في أحد ثلاثة مواضع: تضيع التحديثات عند دخول تغذية البورصة، أو يُركَّب الدفتر بشكل خاطئ، أو يصل إلى مئات الشاشات ببطء شديد. قِس أكثر ساعاتك ازدحامًا قبل أن تستعين بأي أحد، ثم اختبر كل شركة تفكر فيها على تسجيل لذلك اليوم.

كيف تبدو تغذية بيانات السوق المعطّلة على الشاشة؟

يظهر ذلك في أشد اللحظات ازدحامًا، مثل إعلان من البنك المركزي أو افتتاح السوق. يتوقف الدفتر على الشاشة ثانية أو ثانيتين، ثم يقفز. وتبقى الأوامر الملغاة ظاهرة. وأحيانًا يكون أعلى سعر يعرضه مشترٍ أعلى من أدنى سعر يطلبه بائع، وهذا ما يُسمّى الدفتر المتقاطع (crossed book). وفي بورصة واحدة، خارج مزادَي الافتتاح والإغلاق، كانت أوامر كهذه ستتطابق فورًا. لذا فإن ظهور دفتر متقاطع لبورصة واحدة على شاشتك يعني أن نسختك من ذلك الدفتر خاطئة.

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

لماذا تضيع التحديثات أو تصل خارج الترتيب؟

تغذية دفتر الأوامر من البورصة تدفق من تغييرات صغيرة: أمر أُضيف، وأمر أُلغي، وصفقة. ويبدأ نظامك من نسخة كاملة من الدفتر تُسمّى اللقطة (snapshot)، ثم يطبّق التغييرات بالترتيب. وكل تغيير مرقّم، لذا يمكن اكتشاف التغيير الناقص. وتقول مواصفة Nasdaq لتغذية TotalView-ITCH 5.0 إن التغذية «تتكوّن من سلسلة من الرسائل المتسلسلة»، أي المرقّمة بالترتيب.

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

البورصات تتوقع أن يفقد عملاؤها تحديثات. فتوثيق CME Group لتغذيتها MDP 3.0 يقول إنه بعد حدوث فجوة «ينبغي افتراض أن جميع الدفاتر المحفوظة في نظام العميل ربما لم تعد على الحالة الصحيحة والأحدث».

في أي موضع من النظام تتعطل التغذية؟

هناك ثلاثة مواضع، ولكل منها إصلاحه الخاص. ويسمّي المهندسون الموضع الثالث fan-out، لأن تدفقًا واحدًا من التحديثات يتفرّع منه إلى شاشات كثيرة. والمقالة التقنية المشار إليها أعلاه تتناول المواضع الثلاثة بالتفصيل.

الموضع الأول هو جانب الاستقبال، حيث تصل تغذية البورصة. وتتيح بعض البورصات طرقًا لاستعادة البيانات الضائعة. فأحد بروتوكولات التوصيل لدى Nasdaq، وهو MoldUDP64، يتيح للمستقبِلين «كشف الحزم الفائتة وإعادة طلبها». وترسل CME تدفقها مرتين، على خطين يُسمّيان A وB، وتشغّل تغذية منفصلة من اللقطات لتحديث الدفاتر. ولا شيء من هذا يفيد إن لم يلحظ نظامك الفجوة.

ثم يُركَّب الدفتر، وهنا يكمن الخطر في تغيير يُطبَّق مرتين، أو خارج الترتيب، أو فوق لقطة غير صحيحة. وتشرح Binance، وهي بورصة للعملات الرقمية، في دليلها الخطوات الدقيقة لوصل اللقطة بالتدفق الحي. والدفتر المبني من دونها يظل يعرض أسعارًا ويبدو سليمًا، لكن الأسعار خاطئة.

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

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

ماذا نقيس قبل أن نستعين بأحد؟

خذ أكثر ساعة ازدحامًا في الشهر الماضي، واجمع لها هذه الأرقام:

• الفجوات: كم مرة وجد النظام رقم تحديث ناقصًا في كل تغذية من تغذيات البورصات. وإن كان النظام لا يعدّها، فهذه أول نتيجة تخرج بها
• زمن التعافي: كم استغرقت كل إعادة بناء، وماذا رأى المتداولون في أثناء ذلك
• التأخير: الزمن من الطابع الزمني الذي تضعه البورصة على الرسالة حتى لحظة خروج التحديث من خادمك إلى المتداول، وعلى بضع طرفيات اختبار حتى ظهوره على الشاشة. وخذ الوسيط والمئين 99، أي الزمن الذي تبقى دونه 99 تحديثًا من كل 100. وأبقِ ساعات خوادمك متزامنة مع مصدر وقت دقيق، وإلا فلا معنى للأرقام
• الجلسات: كم جلسة تأخرت، وبأي قدر، وكم جلسة قُطع اتصالها، مع سبب كل قطع

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

نُصلح معالج التغذية لدينا، أم نشتري واحدًا، أم نعيد بناء الـ fan-out؟

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

متى يكون إصلاح معالج التغذية لدينا خيارًا منطقيًا؟

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

• متى يناسبك: عيب تستطيع تسميته، وتصميم يعمل جيدًا في ما عدا ذلك
• ما تدفعه: وقت الهندسة، ومنصة اختبار تعيد تشغيل تسجيلاتك
• من يملك الكود: أنت
• القيد: إصلاح جانب الاستقبال لا يفيد إن كانت المشكلة في إرسال الدفتر إلى الشاشات

متى ينبغي أن نشتري معالج تغذية أو تغذية مُدارة؟

معالج التغذية الجاهز برنامج مرخّص يتصل بالبورصة، ويلتقط الفجوات، ويسلّم نظامك دفترًا صحيحًا ومحدَّثًا. أما التغذية المُدارة فتذهب أبعد من ذلك: يتصل مزوّد بيانات السوق بالبورصات، وتتلقى أنت منه تدفقًا واحدًا بصيغة واحدة.

• متى يناسبك: بورصات كثيرة بصيغ قياسية، وعدم رغبة في متابعة كل تغيير تجريه كل بورصة على تغذيتها
• ما تدفعه: الترخيص، والعمل اللازم لربط المنتج بنظامك. وتبقى رسوم البيانات وشروط الترخيص الخاصة بالبورصات نفسها سارية في العادة، أيًّا كانت الجهة التي توصل البيانات
• ما يبقى على عاتقك: إيصال الدفتر إلى مئات شاشات المتداولين، والتعامل مع الجلسات البطيئة
• من يملك الكود: المورّد يملك المنتج. وأنت تملك التكامل وكل ما يأتي بعده

متى ينبغي أن نستعين بفريق لإعادة بناء الـ fan-out؟

أعد بناء الطبقة التي ترسل البيانات إلى المتداولين حين يعمل جانب الاستقبال جيدًا لكن المشكلة باقية: ما زال المتداولون يرون دفاتر مختلفة، أو تُبطئ جلسة بطيئة واحدة سائر الجلسات، أو تخطط لخدمة جلسات أكثر بكثير مما لديك اليوم.

• متى يناسبك: حين يكبر التأخير بين خوادمك والشاشات، لا بين البورصة وخوادمك
• ما تدفعه: وقت الهندسة والاختبار، ثم الأشخاص الذين يشغّلون النظام بعد الإطلاق
• من يملك الكود: أنت، إن نصّ العقد على ذلك

كيف نتحقق من شركة قبل أن نستعين بها؟

أخضِع كل شركة في قائمتك للاختبارات الخمسة نفسها:

• إعادة تشغيل تسجيلك، بالسرعة الفعلية وبسرعة تفوقها بعدة أضعاف، عبر ما تسلّمه الشركة أو تعرضه. وقارن الفجوات وعمليات إعادة البناء وأزمنة التعافي والتأخير الناتجة عنها بنظيراتها في نظامك الحالي
• كيف يلتقط الفجوة. الجواب الجيد يقول إن النظام لا يطبّق التغيير إلا حين يكون رقمه هو التالي المتوقع. وإن كان رقم ما ناقصًا، ينتظر النظام قليلًا، ثم يطلب التغيير من جديد أو يعيد بناء الدفتر. وإلى أن يحدث ذلك، يضع على الدفتر علامة بأنه غير محدَّث. واسأل ماذا يرى المتداولون في أثناء ذلك
• ماذا يحدث لمتداول بطيء واحد. اطلب من الشركة أن تبطّئ جلسة واحدة عمدًا أثناء إعادة التشغيل. ويجب ألا يتغير التأخير في الجلسات الأخرى
• كيف يقيس التأخير: من أي طابع زمني إلى أي نقطة، وعند أي مئين، وتحت أي حمل، وعلى أي عتاد، وكيف تُبقى الساعات متزامنة
• من يملك الكود، وبأي شروط تستخدم أي أجزاء تحتفظ بها الشركة لنفسها

ما العلامات التحذيرية؟

• «سنضيف مزيدًا من الخوادم» جوابًا أول، قبل أن يطّلع أحد على قياساتك
• «نستخدم اتصالًا موثوقًا، فلا يضيع شيء». ترسل Binance تحديثاتها عبر WebSocket، وهو اتصال لا يفقد البيانات أثناء نقلها، ومع ذلك يشرح دليلها للعملاء ما يفعلونه حين تُتخطّى أحداث

أين موقع amBrain من ذلك؟

تبني amBrain بنية تحتية للتداول الخوارزمي: تنفيذ الأوامر، وبيانات السوق، وضوابط المخاطر قبل التداول.

يقول سطر على موقع amBrain: «تطوير طرفيات التداول، وأنظمة إدارة الأوامر، وتكامل البورصات عبر بروتوكول FIX».

تشخّص amBrain الأنظمة البطيئة في التداول وAdTech: تُقاس المنصة أثناء تشغيلها من طرف إلى طرف، ويسمّي التقرير أين يذهب الوقت.

تبني amBrain البرمجيات منذ عام 2019. وتصف فريقها في سطر واحد: «فريق يصل إلى 40 شخصًا، نحو 75% منهم من كبار المهندسين». وتعمل بثلاث صيغ: تسليم كامل، أو فريق مخصّص، أو مهندسون مدمجون في فريقك. ويحتفظ العميل بالملكية الكاملة للمنتج وللكود، باستثناء مكوّنات amBrain القابلة لإعادة الاستخدام.

هذه المقالة ليست دراسة حالة، ولا تصف أي عمل لعميل. ولا تذكر أي رقم لزمن الاستجابة لأي نظام بنته amBrain، ولا أي أسعار أو جداول زمنية.

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

أسئلة شائعة

• هل تحل الخوادم الإضافية المشكلة؟ ليس وحدها. فإن كان النظام يطبّق التغييرات خارج الترتيب أو ينتظر أبطأ جلساته، كررت الخوادم الإضافية العيب نفسه. أضف خوادم حين تُظهر القياسات أن الخوادم الحالية تستنفد سعتها
• هل يمكننا دمج التحديثات وإرسال عدد أقل منها؟ بالنسبة إلى دفتر الأوامر، نعم. ويسمّي المهندسون ذلك conflation، وبعض البورصات تفعله بنفسها. ويحدد توثيق Binance سرعة التحديث في تدفقها الفوري (spot) لتغييرات دفتر الأوامر بـ 1000 ms أو 100 ms. وأبلغ المتداولين أن التدفق يعرض أحدث صورة لا كل خطوة. ولا تدمج الصفقات ولا تأكيدات الأوامر، لأن إسقاط واحد منها يجعل سجل الصفقات خاطئًا
• هل علينا إعادة كتابته بـ Rust أو C++؟ ليس بالضرورة. فالفجوات التي تمر دون أن تُكتشف، والخادم الذي ينتظر أبطأ جلساته، عيوب في التصميم لا تزيلها لغة جديدة. ولا يوجد في Rust وC++ جامع قمامة (garbage collector)، وهو التنظيف التلقائي للذاكرة الذي قد يوقف مؤقتًا برنامجًا مكتوبًا بلغة مثل Java أو Go. وهذا يفيد في أجزاء النظام التي تعالج كل تحديث. وأيًّا كانت اللغة، فاطلب التأخير المقيس في الذروة
• كم يستغرق الإصلاح؟ يتوقف ذلك على موضع العيب، وعلى عدد البورصات والجلسات لديك. واطلب من كل شركة أن تسعّر مرحلة أولى وتضع لها جدولًا زمنيًا، على أن تشمل القياسات وبيئة اختبار تعيد تشغيل تسجيلك. واجعل الاختبارات الخمسة أعلاه معايير النجاح فيها