نظام إدارة متعدد للشموع (Kline) لأتمتة التداول على نطاق واسع

نظرة عامة

نظام إدارة الـ Multi-Kline يمكّن MagicTradeBot من تحميل وتخزين مؤقت وصيانة بيانات الشموع (kline) لعدة أطر زمنية لمئات الآلاف من أزواج التداول في نفس الوقت بكفاءة عالية، مع الالتزام التام بحدود معدل استدعاءات API الخاصة بالمنصات. هذه الميزة تدعم استراتيجيات تداول متنوعة تمامًا — من السكالبينج عالي التردد إلى التداول الاستثماري طويل الأجل — وكلها تعمل بالتوازي مع عزل كامل بينها.

القدرات الأساسية

تحميل الأطر الزمنية حسب الاستراتيجية

يقوم البوت بتحميل بيانات kline ديناميكيًا بناءً على نوع الاستراتيجية النشطة. كل استراتيجية لها أطر زمنية مثالية محددة مسبقًا:

الأطر الزمنية حسب الاستراتيجية:

  • HFT (التداول عالي التردد): 1m – تنفيذ فائق السرعة على حركات الدقيقة
  • Scalp: 15m – صفقات مومنتم قصيرة الأجل على شارت 15 دقيقة
  • Day Trading: 15m, 30m, 1h, 2h, 4h – تحليل داخل اليوم عبر عدة أطر زمنية
  • Swing Trading: 1h, 2h, 4h, 6h, 12h – أنماط متعددة الساعات لدخول المراكز
  • Long-Term: 1d – شارت يومي لتحليل الاتجاهات الكلية
  • Default: 5m, 15m, 1h – نهج متوازن متعدد الأطر الزمنية

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

إدارة ذكية لحدود المعدل

تقنين الطلبات التكيفي

النظام يطبق خوارزمية متطورة تحترم قيود API المنصات:

  • maxRequestsPerSecond: 10 – الحد الأقصى الصلب للمنصة في الثانية
  • safeBuffer: 0.2 – هامش أمان (يستخدم 80% من السعة القصوى)
  • المعدل الفعلي: 8 طلبات/ثانية (10 × 0.8)

استراتيجية توزيع الطلبات

معالجة الأزواج على دفعات (Chunks):

  • chunk_size: 20 – عدد الأزواج التي يتم جلبها في كل دورة تحديث
  • يوزع مئات الآلاف من الأزواج عبر الزمن
  • يمنع تجاوز حدود الـ burst
وقت معالجة الدفعة = chunk_size / المعدل_الفعلي
مثال: 20 رمزًا / 8 طلب/ث = 2.5 ثانية لكل دفعة

دورة التحديث:

  • kline_refresh_rate: 7 ثوانٍ بين دورات التحديث الكاملة
  • يضمن بقاء البيانات حديثة دون إرهاق الـ API
  • إدراج تأخير تكيفي حسب أوقات الاستجابة

دعم منصات متعددة

  • Binance: 1200 طلب/دقيقة (20/ثانية)
  • OKX: 20 طلب/ثانيتين
  • Bybit: 120 طلب/5 ثوانٍ

البوت يعدّل maxRequestsPerSecond تلقائيًا حسب المنصة المكتشفة.

تخزين Kline موفر للذاكرة

نهج النافذة المتحركة (Rolling Window)

للتعامل مع أعداد هائلة من الأزواج دون استنفاد الذاكرة:

  • إدارة Kline لكل رمز:
    • max_kline_length: 100 – الحد الأقصى للشموع المحتفظ بها لكل إطار زمني
    • مخزن دائري (FIFO)
    • إزالة الشموع القديمة تلقائيًا عند وصول جديدة
كائن Kline واحد: ~200 بايت
لكل رمز (5 أطر × 100 شمعة): ~100 كيلوبايت
100,000 رمز: إجمالي ~10 جيجابايت استهلاك ذاكرة

التحميل الكسول والتخزين المؤقت

  • التحميل الأولي يجلب كامل max_kline_length
  • التحديثات اللاحقة تطلب فقط أحدث الشموع
  • ذاكرة تخزين مؤقت LRU للأزواج غير النشطة
  • الأزواج غير النشطة لمدة 24 ساعة تُزال تلقائيًا من الذاكرة

تنفيذ الاستراتيجيات بالتوازي

ربط الرمز بالاستراتيجية

BTCUSDT:
  strategy: "day"
  intervals: ["15m", "1h", "4h"]
 
ETHUSDT:
  strategy: "scalp"
  intervals: ["15m"]
XRPUSDT:
  strategy: "swing"
  intervals: ["1h", "4h", "12h"]

معالجة الإشارات معزولة

  • signal_refresh_interval: 20 ثانية (قابلة للتخصيص حسب الاستراتيجية)
  • Scalp → كل 20 ثانية
  • Long-term → كل 1800 ثانية (30 دقيقة)

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

هندسة القابلية للتوسع

جلب Kline موزَّع

نظام قائمة انتظار حسب الأولوية:

  1. أولوية عالية (صفقات مفتوحة)
  2. أولوية متوسطة (إشارات قوية)
  3. أولوية منخفضة (مراقبة فقط)
  4. بيانات قديمة (لم تُحدَّث منذ ضعف معدل التحديث)

تحسين طلبات الدفعات:

  • استدعاء API واحد يمكنه جلب عدة أطر زمنية لنفس الرمز
  • يقلل إجمالي الطلبات بنسبة ~40%
  • يستخدم نقاط نهاية الدفعات الخاصة بكل منصة

تحمل الأعطال

  • تجاوز الحد → تراجع أسي (2x، 4x، 8x)
  • فشل الطلب → حتى 3 محاولات إعادة
  • أعطال مستمرة → تعطيل الرمز مؤقتًا
  • فقدان الاتصال → يبقى في الطابور حتى إعادة الاتصال

التحقق من صحة البيانات يشمل:

  • كشف فجوات الطوابع الزمنية
  • كشف انحرافات الأسعار
  • ملء تلقائي للفجوات
  • استبعاد البيانات القديمة

تحسينات الأداء

سير عمل دورة التحديث

كل دورة تحديث (كل 7 ثوانٍ):

  1. مرحلة الاختيار (0.1 ث)
  2. مرحلة الجلب (2.5 ث)
  3. مرحلة المعالجة (1.5 ث)
  4. مرحلة الخمول (2.9 ث)

الإنتاجية الكلية:

  • 2.86 رمز/ثانية
  • 10,285 رمزًا محدَّثًا في الساعة
  • 100,000 رمز يتم تحديثها كل ~9.7 ساعة

تحسينات خاصة بكل استراتيجية

  • Scalp: تحديث أسرع، مخازن أصغر
  • Long-Term: تحديث أبطأ، مخازن قياسية

أفضل ممارسات الإعداد

محفظة صغيرة (<1,000 رمز)

chunk_size: 50
kline_refresh_rate: 5
maxRequestsPerSecond: 15
safeBuffer: 0.3

محفظة متوسطة (1,000–10,000 رمز)

chunk_size: 20
kline_refresh_rate: 7
maxRequestsPerSecond: 10
safeBuffer: 0.2

محفظة كبيرة (>100,000 رمز)

chunk_size: 10
kline_refresh_rate: 10
maxRequestsPerSecond: 8
safeBuffer: 0.15
max_kline_length: 50

ضبط خاص بكل منصة

  • Binance: دفعات أكبر، تحديث أسرع
  • المنصات الصارمة: دفعات أصغر، تحديث أبطأ

مثال واقعي

السيناريو: تداول 50,000 رمز على Binance

chunk_size: 25
kline_refresh_rate: 8
maxRequestsPerSecond: 12
safeBuffer: 0.2
max_kline_length: 80

الأداء:

  • المعدل الفعلي: 9.6 طلب/ثانية
  • معالجة الدفعة: 2.6 ثانية
  • تحديث كامل: كل ~4.4 ساعة
  • استهلاك الذاكرة: ~8 جيجابايت
  • طلبات API يوميًا: ~275,000

تحليلات الملخّص

إعداد summary_interval: "1d" يوفر رؤى يومية تشمل:

  • إجمالي الرموز المراقبة
  • استهلاك API
  • نسبة استغلال حدود المعدل (%)
  • حداثة البيانات
  • الإشارات حسب الاستراتيجية
  • استهلاك الذاكرة

📎 Related Topics