العام الماضي، قمتُ بمشروع بناء لوحة تحكم للمراقبة في الوقت الحقيقي لمنصة تداول. المتطلبات: تصور بيانات السوق المحدثة بمعدل مليون حدث في الثانية مع زمن انتقال أقل من 100 مللي ثانية إلى شاشات المستخدمين.
هذا كسر كل ما اعتقدنا أننا نعرفه عن تصور البيانات.
واقع الوقت الحقيقي
إليكم ما لا يقوله أحد: "الوقت الحقيقي" عادة ليس في الوقت الحقيقي. وهذا غالبًا جيد.
معظم لوحات التحكم المُصنفة "وقت حقيقي" تُحدث فعليًا كل 5-30 ثانية. لمعظم حالات الاستخدام، هذا كافٍ تمامًا. ولكن عندما تحتاج فعليًا تحديثات بأقل من الثانية، تتغير القواعد تمامًا.
المستويات الثلاثة لـ "الوقت الحقيقي"
المستوى 1: شبه الوقت الحقيقي (تحديث كل 5-60 ثانية)
حالات الاستخدام: لوحات تحكم الأعمال، تحليلات التسويق، مقاييس المبيعات
الهيكلية: استطلاع نقاط نهاية API، تجميع دفعات
التعقيد: متوسط
هذا ما يحتاجه معظم الناس. فريق البيانات يُجمّع البيانات كل دقيقة، لوحة التحكم تستطلع التحديثات. بسيط وفعال.
المستوى 2: الوقت الحقيقي (تحديث كل 1-5 ثوانٍ)
حالات الاستخدام: مراقبة العمليات، تتبع الأحداث المباشرة، طوابير دعم العملاء
الهيكلية: WebSockets، أحداث مرسلة من الخادم، استعلامات التدفق
التعقيد: مرتفع
الانتقال من الاستطلاع إلى الدفع يغير كل شيء. الآن أنت تحافظ على اتصالات مستمرة، تتعامل مع منطق إعادة الاتصال، وتدير الحالة عبر الخادم/العميل.
المستوى 3: أقل من الثانية (أقل من 1 ثانية)
حالات الاستخدام: منصات التداول، إحصائيات الألعاب المباشرة، المراقبة الصناعية
الهيكلية: خطوط أنابيب التدفق، قواعد بيانات متخصصة، عرض محسّن
التعقيد: مرتفع جدًا
هذا هو المكان الذي عشنا فيه لمدة 8 أشهر. كل تحسين مهم. كل ميلي ثانية تُحتسب.
لماذا تصور الوقت الحقيقي صعب
المشكلة 1: حجم البيانات
عند مليون حدث/الثانية، لا يمكنك عرض كل حدث. هذا مليون نقطة كل ثانية. المتصفح سينفجر.
الحل: التجميع المسبق. لا ترسل الأحداث الخام إلى الواجهة الأمامية. جمّع عند المصدر—المتوسطات، الأعداد، النسب المئوية لكل فترة زمنية. أرسلنا 10 تحديثات مجمعة في الثانية بدلًا من مليون حدث خام.
المشكلة 2: أداء العرض
حتى مع 10 تحديثات في الثانية، إعادة عرض المخططات بأكملها يقتل الأداء. مصالحة React، معالجة SVG، إعادة رسم canvas—تتراكم.
الحل: تحديثات تزايدية. لا تعيد بناء المخطط؛ أضف إليه. استخدمنا عرضًا قائمًا على WebGL للمخططات عالية التردد، والتي يمكنها التعامل مع تحديثات 60 إطار/ثانية بسلاسة.
المشكلة 3: الإدراك البشري
هنا النتيجة غير البديهية: التحديثات الأسرع من ~200 مللي ثانية تصبح ضبابية. المستخدمون لا يستطيعون معالجة المعلومات عند 10+ إطار/ثانية. هم فقط يرون وميضًا.
الحل: تهدئة بصرية. حتى عندما تتحدث البيانات بسرعة 10 هرتز، حركنا التحولات على مدار 200 مللي ثانية. شعر المخطط بأنه "مباشر" دون أن يشعر بالفوضى.
المشكلة 4: تقلب الشبكة
اتصالات WebSocket تنقطع. الحزم تتأخر. مستخدمو الهواتف المحمولة يغيرون الشبكات.
الحل: إعادة اتصال قوية، قائمة انتظار الرسائل، وتدني سلس. إذا انقطع الاتصال، اعرض آخر حالة معروفة مع مؤشر "يعيد الاتصال"—لا تظهر شاشة فارغة.
الهيكلية التي نجحت
إليكم المكونات التي تعاملت مع متطلب مليون حدث في الثانية:
طبقة البيانات
- Apache Kafka لاستيعاب الأحداث
- Apache Flink للتجميع في الوقت الحقيقي
- Redis للتخزين المؤقت لأحدث الحالات
- TimescaleDB للاستعلامات التاريخية
طبقة API
- Go لخادم WebSocket (يتعامل مع الاتصالات المتزامنة بكفاءة)
- gRPC للتواصل الداخلي بين الخدمات
- تجميع الرسائل (أرسل التحديثات كل 100 مللي ثانية، وليس كل حدث)
الواجهة الأمامية
- React لهيكل واجهة المستخدم
- WebGL (عبر regl) للمخططات عالية التردد
- Canvas خفيف الوزن للمخططات متوسطة التردد
- SVG (عبر D3) فقط للمخططات منخفضة التردد والغنية بالتفاعل
قرارات رئيسية
- جمّع بأسرع وقت ممكن: يجب أن تستقبل الواجهة الأمامية بيانات جاهزة للعرض، وليس أحداثًا خام.
- افصل ترددات التحديث: ليس كل عنصر يحتاج 10 إطار/ثانية. السياق الثابت يمكن أن يتحدث كل 30 ثانية.
- مستوى التفاصيل الذي يتحكم به المستخدم: دع المستخدمين يختارون بين "نظرة عامة" (تحديثات أبطأ، بيانات أكثر) و "مفصل" (تحديثات أسرع، عرض مركّز).
تحسينات الأداء
على الخادم
- احسب الفترات الزمنية مسبقًا: لا تجعل العميل يحسب "آخر 5 دقائق"
- ترميز الدلتا: أرسل فقط ما تغير، وليس الحالة الكاملة
- الضغط: gzip رسائل WebSocket (فعال بشكل مدهش)
- تجميع الاتصالات: أعد استخدام الاتصالات عبر الاشتراكات
على العميل
- تجميع الكائنات: أعد استخدام عناصر المخطط بدلًا من جمع المهملات
- تجميع RequestAnimationFrame: زامن التحديثات مع دورة عرض المتصفح
- طبقات canvas: العناصر الثابتة على canvas واحد، الديناميكية على آخر
- Web Workers: اتحليل البيانات الواردة خارج الخيط الرئيسي
ما لم ينجح
- SVG للتحديثات عالية التردد (معالجة DOM بطيئة جدًا)
- Redux لحالة الوقت الحقيقي (كثير من النفقات العامة للتحديثات المتكررة)
- مكتبات المخططات الجاهزة لأكثر من 5 إطار/ثانية (غير محسّنة لهذه الحالة الاستخدام)
دروس تجربة المستخدم من الوقت الحقيقي
الدرس 1: أعط المستخدمين التحكم
ليس الجميع يريد تحديثات مباشرة. بعض المستخدمين يجدونها مشتتة. أضفنا:
- زر إيقاف مؤقت: "جمّد" العرض الحالي
- محدد تردد التحديث: 1 ثانية، 5 ثوانٍ، 30 ثانية
- وضع تاريخي: "أرني ما حدث قبل 5 دقائق"
الدرس 2: اجعل الحالة واضحة
يحتاج المستخدمون لمعرفة:
- هل هذا مباشر أم تاريخي؟
- متى كان آخر تحديث؟
- هل الاتصال سليم؟
أضفنا مؤشر "نبض قلب" ثابتًا ينبض مع كل تحديث. كان مطمئنًا بشكل مدهش.
الدرس 3: تعامل مع الحالات المملة
معظم الوقت، لا يحدث شيء مثير للاهتمام. المخطط فقط... يتحدث بقيم متشابهة.
هنا تساعد التعليقات التوضيحية: "تم اكتشاف ارتفاع عند 14:32" يجذب الانتباه إلى التغييرات المهمة. بدونه، يحدق المستخدمون في ضوضاء.
الدرس 4: الهاتف المحمول مختلف
شاشات أصغر، اتصالات أسوأ، قيود بطارية. للهاتف المحمول:
- قلل تردد التحديث تلقائيًا
- بسّط التصورات
- أضف منطق إعادة اتصال قويًا
عندما لا يستحق الوقت الحقيقي
بعد بناء هذا النظام، أصبحت أكثر تشككًا في متطلبات الوقت الحقيقي. اسأل:
- هل التحديثات الأسرع ستغير سلوك المستخدم؟
- هل يستطيع المستخدمون فعلاً التصرف بناءً على معلومات بهذه السرعة؟
- هل التكلفة الهندسية مبررة؟
لمعظم لوحات التحكم، الجواب هو لا. تحديث كل 15 ثانية جيد. احفظ الوقت الحقيقي للحالات التي تُحدث الثواني فرقًا فيها.
أدوات وموارد
للمستوى 1-2 (شبه الوقت الحقيقي والوقت الحقيقي):
أدوات حديثة مثل ChartGen يمكنها توليد مخططات تستطلع نقاط نهاية API بفعالية. بالاقتران مع نقاط نهاية WebSocket، يمكنك بناء لوحات تحكم وقت حقيقي قوية بدون بنية تحتية مخصصة.
للمستوى 3 (أقل من الثانية):
ستحتاج أدوات متخصصة: D3 مع canvas، عرض WebGL مخصص، أو مكتبات مبنية لغرض محدد مثل uPlot أو Apache ECharts مع وضع التحديث التزايدي.
لبنية تحتية التدفق:
- Apache Kafka + Flink (معقد ولكن قوي)
- AWS Kinesis + Lambda (مدير لكن محدود)
- Redis Streams + تجميع مخصص (أبسط لكن أقل قابلية للتوسع)
مراقبة نظام وقتك الحقيقي
ما قسناه:
- زمن الانتقال من النهاية للنهاية (طابع زمني الحدث إلى البكسل على الشاشة)
- صحة الاتصال (إعادة اتصالات في الساعة)
- أداء العرض (إطارات في الثانية)
- تفاعل المستخدم (هل يشاهد الناس حقًا عرض الوقت الحقيقي؟)
نتيجة مدهشة: العديد من المستخدمين فتحوا لوحة التحكم، شاهدوا لمدة دقيقتين، ثم تركواها في علامة تبويب خلفية. البيانات "المباشرة" كانت غير مرئية غالبًا.
فكرة أخيرة
تصور الوقت الحقيقي هو تحدٍ هندسي، ولكنه أيضًا تحدٍ لتجربة المستخدم. الجزء الأصعب ليس إيصال البيانات للشاشة بسرعة—بل عرضها بطريقة يمكن للبشر فهمها والتصرف بناءً عليها.
قبل بناء الوقت الحقيقي، اسأل: ماذا سيفعل المستخدمون فعلاً بشكل مختلف مع بيانات أسرع؟
إذا لم يكن الجواب واضحًا، قد لا تحتاج الوقت الحقيقي من الأساس.