متابعةً للمقالات الثلاث السابقة حول رمز التداول الآلي في السوق:

المحتوى الجاد - تفاصيل وأفكار حول نظام التداول الكمي الآلي (واحد مشاكل وصعوبات)

نظام التداول الكمي - تفاصيل وأفكار حول التشغيل الآلي (اثنان الغرض من التشغيل)

نظام التداول الكمي - تفاصيل وأفكار حول التشغيل الآلي (ثلاثة تقنيات المعالجة)

دعني أواصل الحديث عن نظام التداول متعدد الاستراتيجيات، ومركز السوق في الهيكل العام لأكواد التشغيل.

مقدمة

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

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

في عالم التداول، حيث تكون الطبيعة البشرية كحلبة شياطين، النجوم سهلة الحصول عليها، لكن الأجداد نادرا ما يُعثر عليهم.

كنوع من المتداولين الكميين الذين بقوا على قيد الحياة، أعتقد أن إحدى النقاط المهمة في التداول هي إدراك ضرورة تعدد الاستراتيجيات. من الصعب تحقيق تعدد الاستراتيجيات في التداول الذاتي، نظرًا للقيود البشرية (ما لم يتم توظيف العديد من المتداولين كما تفعل المؤسسات) ومن السهل تفويت نقاط الدخول في السوق التي تعمل على مدار 24 ساعة. لكن التداول الآلي، من السهل تحقيقه. يفقد التداول الآلي القدرة على التعرف على أنماط حركة الأسعار من خلال العقل البشري، لكنه يتمتع بقوة تنفيذ أكبر، وقدرة أفضل على نسخ الاستراتيجيات وتوزيع المراكز، مما له فوائد وسلبيات.

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

نظرة عامة

الصورة أدناه هي مخطط تقريبي لبنية مجموعة من أكواد التشغيل الخاصة بي.

تتكون الهيكلة بالكامل من جزئين. الجزء الأول هو مركز سوق مستقل، والجزء الثاني هو البرنامج المسؤول عن تنفيذ منطق الاستراتيجية.

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

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

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

عندما يكون عدد التطبيقات قليلًا، يمكنك استخدام أدوات مثل tmux لعرض معلومات السجل (log) في الوقت الحقيقي، مما يجعل المراقبة في بداية تشغيل البرنامج أمرًا سهلاً للغاية. بعد استقرار الشيفرة، يمكنك استخدام برمجيات مثل pm2 لإدارة التشغيل. لاحقًا، يمكنك تحليل ملفات السجل بشكل دوري.

في حالة وجود استراتيجيات متعددة الأهداف، يصبح وجود مركز سوق مستقل أمرًا أساسيًا. يمكن مشاركة المعلومات السوقية المختلفة المستخرجة بين عدة برامج تداول، أي تلك الوحدات الاستراتيجية الموجودة على الجانب الأيسر من الصورة أعلاه.

مركز السوق

الصورة أدناه هي مخطط أكثر تفصيلًا لوحدة مركز السوق.

أولاً، يمكنك استخدام ملف التكوين لتحديد الرموز (symbols) الخاصة بالشموع (k-line) التي تحتاج إلى الحصول عليها، مما يسهل تغيير الأنواع لاحقًا.

إذا كانت متعددة الفترات، فيمكن الحصول على الفترة المشتركة للشموع (k-line) الخاصة بهم، ثم يمكن لكل استراتيجية إعادة أخذ عينات حسب احتياجاتها.

إذا كنت ترغب في تبسيط ذلك، وجعل الأمور أكثر سهولة، فإن الحصول على شمعة (k-line) كل 15 دقيقة هو الأفضل، لأن استراتيجيات متوسطة إلى منخفضة التردد، خاصة تلك التي تتبع الاتجاه، يكون من الصعب كسب المال على المدى الطويل إذا كانت الفترات أقل من 15 دقيقة.

على سبيل المثال، إذا كان لديك استراتيجيات لكل من 15 دقيقة، 1 ساعة، و4 ساعات، فإن مركز السوق يحتاج فقط للحصول على شموع (k-line) كل 15 دقيقة. إذا كان طول الشموع المستخرجة من الفترات الزمنية الكبيرة غير كافٍ بعد إعادة أخذ العينات، فسيتعين عليك حفظ المزيد من الشموع كل 15 دقيقة في قاعدة البيانات عند بدء التشغيل.

لأن websocket يرسل فقط معلومات الشمعة (k-line) التي تم تحديثها مؤخرًا، إذا كانت الفترات الزمنية المستخدمة في استراتيجيتك كبيرة، وفترة العودة طويلة، مثل ma150 لكل 4 ساعات، سيكون ذلك 600 ساعة (25 يومًا) من البيانات، وإذا كانت كل شمعة 15 دقيقة، فسنحتاج إلى 2400 شمعة. يعتمد ذلك على بدء مركز السوق، من خلال واجهة برمجة التطبيقات (rest api) للحصول على البيانات وحفظها دفعة واحدة، كأساس للتحديث المستمر لاحقًا.

لقد قسمت مركز السوق إلى تطبيقين. يمكن دمجهما في تطبيق واحد، لكن الفصل بينهما يجعل الأمور أكثر قوة. دعني أبدأ بالتحدث عن PlanB.

PlanB

ذكرت في المقالات السابقة أن هذا بشكل أساسي لمنع انقطاع websocket في PlanA، وهو احتياطي مؤقت، خصوصًا في لحظة الخروج من الاستراتيجية، لتجنب أن يكون السعر قد تحرك في الاتجاه المعاكس لمسافة معينة، ولا يزال يتعين الخروج من الصفقة مما يسبب المزيد من الخسائر غير المتوقعة.

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

حاليًا، يوجد في بينانس حوالي 200 عقد دائم، إذا تم الحصول على الأسعار الجديدة لكل منها بشكل منفصل، لضمان تحديث سعر كل نوع كل 3 ثوانٍ، سيكون من الضروري استدعاء أكثر من 4000 مرة لواجهة برمجة التطبيقات في دقيقة واحدة، مما يتجاوز الحد، ومن غير الممكن تحقيق ذلك. لكن الوظيفة المذكورة سابقًا لها وزن API يبلغ 2 فقط، فإذا تم الحصول عليها كل 3 ثوانٍ، فلن تستهلك أكثر من 40 مرة من حصة واجهة برمجة التطبيقات في الدقيقة، مما يعني أنك لا تحتاج للقلق بشأن تجاوز الحد.

من خلال اختباري، تجمع بينانس الأسعار لكل العقود تقريبًا كل 1-2 ثانية، لذلك بالنسبة للأسعار الاحتياطية للاستراتيجيات متوسطة إلى منخفضة التردد، فإن تأخير حوالي 5 ثوانٍ يكفي تمامًا.

إذا لم تكن المتطلبات مرتفعة، يمكنك حتى استخدامها لتوليف جميع العقود إلى شموع (k-line) خفيفة، مما يتجنب تمامًا استخدام حلول websocket. حتى لو لم يكن بالإمكان استخدام هذه الشموع للتداول، يمكن استخدامها مثل مسح معلومات السوق بالكامل، ثم بناءً على خوارزمية الاستراتيجية التي صممتها، مثل تباعد المتوسطات المتحركة، والتقارب، والتعرف على الأنماط البسيطة، وما إلى ذلك، لتوفير إشارات دخول للمتداولين الذاتي. خلاف ذلك، مع وجود العديد من العملات، كيف يمكن متابعة كل ذلك؟ إذا كان هناك متداول نهاري ذو مستوى عال، قد تكون هذه الأداة مفيدة، كمساعد للتداول. لقد قمت سابقًا بإنشاء أدوات مماثلة للآخرين، وكانت جيدة عندما كان السوق جيدًا، لكن مؤخرًا لم يكن هناك الكثير من الحركة.

بالطبع، هذا الحل له فائدة عملية فقط عند تداول العديد من العملات. وإلا، فإنه من الأفضل الحصول على أسعار BBO لكل نوع مباشرة.

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

PlanA

الرمز الرئيسي لمركز السوق. يحتوي هذا التطبيق على 4 وظائف رئيسية.

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

2. إدارة websocket. هذه الوحدة معقدة بعض الشيء، تحتاج إلى معالجة حالات الانقطاع المختلفة وإعادة الاتصال، وما إلى ذلك. في كل مرة يتم فيها دفع بيانات الشمعة الجديدة من البورصة، يتم تحديث بيانات آخر بار في قاعدة البيانات.

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

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

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