طوابير الرسائل والبنية المدفوعة بالأحداث

🎯 السؤال الأساسي

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

1. لماذا نحتاج إلى "طوابير الرسائل"؟

1.1 قصة من الواقع: تطور نظام الطلبات في تاوباو

في عام 2012، تعرض نظام الطلبات في تاوباو لعطل كبير. عند منتصف ليلة عيد العزاب (11.11)، تدفقت حركة المرور فجأة، واستدعت خدمة الطلبات مباشرة خدمة المخزون، وخدمة الدفع، وخدمة الخدمات اللوجستية... وانهار المسار بأكمله مثل قطع الدومينو.

البنية في ذلك الوقت (اقتران محكم):

يقدم المستخدم طلبًا ← خدمة الطلبات ← استدعاء متزامن لخدمة المخزون ← استدعاء متزامن لخدمة الدفع ← استدعاء متزامن لخدمة الخدمات اللوجستية
                               ↓                    ↓                    ↓
                         زمن الاستجابة 200ms    زمن الاستجابة 500ms    زمن الاستجابة 300ms

⚠️ المشاكل القاتلة للاقتران المحكم

زمن الاستجابة الإجمالي = 200 + 500 + 300 = 1000ms (ينتظر المستخدم ثانية كاملة)
تعطل خدمة المخزون ← تعطل خدمة الطلبات أيضًا (استنفاد تجمع الخيوط)
تباطؤ خدمة الدفع ← تباطؤ المسار بأكمله
استحالة التوسع الأفقي ← التوسع الرأسي فقط (مكلف ومحدود)

البنية المحسّنة (مع إدخال طوابير الرسائل):

يقدم المستخدم طلبًا ← خدمة الطلبات ← إرسال رسالة "تم إنشاء الطلب" ← رد فوري (50ms)
                                        ↓
                              طابور الرسائل (Kafka)
                                        ↓
                  ┌─────────────┬─────────────┬─────────────┐
                  ▼             ▼             ▼             ▼
            خدمة المخزون   خدمة الدفع   خدمة اللوجستيات  خدمة الإشعارات
           (خصم غير متزامن) (معالجة غير متزامنة) (إنشاء غير متزامن) (إرسال غير متزامن)

✨ النتائج بعد التحسين

زمن استجابة المستخدم = 50ms (تحسن في التجربة بمقدار 20 ضعفًا)
تعطل خدمة المخزون ← تخزين الرسائل مؤقتًا في الطابور، واستئناف المعالجة بعد التعافي
تباطؤ خدمة الدفع ← لا يؤثر على إنشاء الطلب
التوسع الأفقي ممكن ← فقط قم بزيادة نسخ المستهلكين

1.2 تشبيه طوابير الرسائل من الحياة اليومية

نظام النداء في المطاعم

تخيل أنك ذهبت إلى مطعم مشهور:

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

طابور الرسائل هو "نظام النداء" في أنظمة البرمجيات:

المنتج (الشخص الذي يطلب) ← يضع الرسالة (الطلب) في الطابور
الطابور (جهاز النداء) ← يخزن الرسائل مؤقتًا
المستهلك (الطاهي) ← يعالج الرسائل وفقًا لإيقاعه الخاص

Processing capacity (Consumer)200 req/s

Maximum backend processing speed

Queue capacity (Queue Size)2000

Maximum requests the message queue can buffer

Current inbound traffic

100 req/s

Queue backlog

0 msgs

Actual processing rate

0 req/s

Rejected requests (rate limited)

0 req

Inbound traffic (user requests)Processed traffic (system load)Queue backlog

💡

Core principle: When inbound traffic (blue) exceeds processing capacity (green line), extra requests are stored in the message queue (orange area).
After the traffic peak passes, the system keeps processing the backlog at full speed until the queue is empty. This is peak shaving.

2. ما هو طابور الرسائل؟ (التعريف + العناصر الأساسية الثلاثة)

2.1 ما هو "طابور الرسائل"؟

🤔 شرح المصطلح

طابور الرسائل (Message Queue, MQ) هو حاوية لتخزين الرسائل، حيث يضع المنتج الرسائل فيها، ويأخذ المستهلك الرسائل منها لمعالجتها. وهو يحقق "الاتصال غير المتزامن" — لا يحتاج المرسل إلى انتظار انتهاء المستقبل من المعالجة.

متزامن مقابل غير متزامن:

متزامن: مثل المكالمة الهاتفية، يجب على الطرف الآخر الرد للتواصل
غير متزامن: مثل إرسال رسالة على الواتساب، ترسلها فقط وسيراها الطرف الآخر عندما يتفرغ

إنه مثل الاتصال بصديق (متزامن) مقابل إرسال رسالة واتساب (غير متزامن).

2.2 العناصر الأساسية الثلاثة لطابور الرسائل

العنصر الأول: المنتج (Producer)

المسؤولية: إنشاء الرسائل وإرسالها إلى الطابور.

تشبيه من الحياة: المنتج مثل "المرسل"، يضع الرسالة في مكتب البريد (الطابور).

نقاط التصميم الرئيسية

طريقة الإرسال: إرسال متزامن (موثوق لكنه مُعيق) مقابل إرسال غير متزامن (أداء عالي لكنه يحتاج لمعالجة الردود)
تأكيد الرسالة: انتظار تأكيد الوسيط (At Least Once) مقابل الإرسال والنسيان (At Most Once)
معالجة الفشل: استراتيجية إعادة المحاولة، النسخ الاحتياطي المحلي للسجلات، طابور الرسائل الميتة

العنصر الثاني: المستهلك (Consumer)

المسؤولية: جلب الرسائل من الطابور ومعالجتها.

تشبيه من الحياة: المستهلك مثل "المستلم"، يأخذ الرسالة من صندوق البريد (الطابور) ويعالجها.

نقاط التصميم الرئيسية

نمط الاستهلاك: نمط الدفع (Push، الوسيط يدفع الرسائل بنشاط) مقابل نمط السحب (Pull، المستهلك يسحب بنشاط)
تأكيد الاستهلاك: ACK تلقائي (فعال لكن قد يفقد رسائل) مقابل ACK يدوي (موثوق لكنه يحتاج لمعالجة المهلات)
التحكم بالتزامن: استهلاك تسلسلي بخيط واحد مقابل استهلاك متوازي متعدد الخيوط
معالجة الفشل: استراتيجية إعادة المحاولة، طابور الرسائل الميتة، آلية التعويض

العنصر الثالث: الوسيط (Broker)

المسؤولية: استقبال الرسائل وتخزينها وإعادة توجيهها.

تشبيه من الحياة: الوسيط مثل "مكتب البريد" أو "محطة فرز الطرود"، مسؤول عن استقبال وفرز وتوصيل الرسائل.

نقاط التصميم الرئيسية

نموذج التخزين: تخزين في الذاكرة (زمن انتقال منخفض) مقابل تخزين على القرص (موثوقية عالية)
استراتيجية النسخ: نسخ رئيسي-تابع، مزامنة نسخ متعددة
آلية التوفر العالي: نشر عنقودي، تجاوز الفشل التلقائي
قابلية التوسع: التقسيم (Partition)، التجزئة (Sharding)

3. السؤال الأساسي الأول: كيف نفصل اقتران النظام لتجنب "تحريك خيط واحد يحرك الكل"؟

3.1 مأساة الاقتران المحكم: تعطل خدمة واحدة يؤدي لانهيار الكل

استعراض السيناريو: البنية المبكرة لمنصة تجارة إلكترونية

خدمة الطلبات تستدعي الخدمات الأدنى مباشرة:
┌─────────────┐
│  خدمة الطلبات  │
└──────┬──────┘
       │
       ├───────────┬───────────┬───────────┐
       ▼           ▼           ▼           ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│خدمة المخزون│ │خدمة الدفع  │ │خدمة اللوجستيات│ │خدمة الرسائل│
│  200ms   │ │  500ms   │ │  300ms   │ │  100ms   │
└──────────┘ └──────────┘ └──────────┘ └──────────┘

📊 جدول تحليل نقاط الألم

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

3.2 حل فصل الاقتران: إدخال طابور الرسائل "كطبقة وسيطة"

البنية بعد فصل الاقتران:

خدمة الطلبات مسؤولة فقط عن إرسال الرسائل، ولا تهتم بمن يستهلك:

┌─────────────┐
│  خدمة الطلبات  │ ──إرسال رسالة "تم إنشاء الطلب"──┐
└─────────────┘                       │
                                      ▼
                            ┌───────────────────┐
                            │    طابور الرسائل    │
                            │  (Kafka/RabbitMQ) │
                            │   - تخزين موثوق     │
                            │   - نسخ متعددة      │
                            │   - ضمان الترتيب    │
                            └─────────┬─────────┘
                                      │
              ┌───────────────────────┼───────────────────────┐
              │                       │                       │
              ▼                       ▼                       ▼
       ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
       │   خدمة المخزون │      │   خدمة الدفع   │      │خدمة اللوجستيات│
       │  اشتراك في حدث  │      │  اشتراك في حدث  │      │  اشتراك في حدث  │
       │     الطلب      │      │     الطلب      │      │     الطلب      │
       └──────────────┘      └──────────────┘      └──────────────┘

🔗System Decoupling DemoFrom tight coupling to loose coupling

❌ The fatal problem of tight coupling

Order service

Create order

Call inventory service

Call points service

Call notification service

Notification service

Send SMS/email

⚠️Strong dependency: notification failure blocks order creation

⚠️Slow response: total time = 300ms + 500ms + 400ms = 1200ms

⚠️Hard to extend: adding a service requires changing order code

💡Core idea:Synchronous calls create strong dependencies and slow responses; asynchronous messaging decouples systems, improves response speed, and scales more easily.

✨ فوائد فصل الاقتران

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

3.3 جوهر فصل الاقتران: من "الاستدعاء المباشر" إلى "البنية المدفوعة بالأحداث"

التحول في نمط التفكير:

التفكير التقليدي (نمط الأوامر):
"خدمة الطلبات تأمر خدمة المخزون: اخفض المخزون!"
  ↓ استدعاء مباشر
  ↓ اقتران عالٍ، يجب أن يكون الطرف المستدعى متصلاً
  ↓ يحتاج المستدعي إلى معرفة واجهة الطرف المستدعى

التفكير المدفوع بالأحداث (نمط التصريح):
"خدمة الطلبات تعلن: تم إنشاء الطلب، من يهتم فليعالجه."
  ↓ إرسال حدث إلى طابور الرسائل
  ↓ فصل الاقتران، يمكن للمستهلك أن يكون غير متصل
  ↓ لا يحتاج المنتج إلى معرفة وجود المستهلكين

4. السؤال الأساسي الثاني: كيف نخفف القمم ونملأ الوديان لمواجهة ارتفاعات حركة المرور؟

4.1 سيناريو البيع الخاطف: كيف نعالج 100 ألف QPS بسلاسة؟

استعراض السيناريو: نشاط بيع خاطف في عيد العزاب (11.11) لمنصة تجارة إلكترونية، الذروة المتوقعة 100 ألف QPS، لكن قاعدة البيانات لا تتحمل سوى 1000 QPS.

نتائج التأثير المباشر:

طلب المستخدم ──→ خادم التطبيق ──→ قاعدة البيانات
  100 ألف/ثانية   100 ألف/ثانية          1000/ثانية (الحد الأقصى)
                                        ↓
                                    استنفاد تجمع الاتصالات
                                    مهلة الاستجابة
                                    انهيار قاعدة البيانات
                                        ↓
                              تأثير الانهيار الجليدي (تعطل كل الخدمات المعتمدة على قاعدة البيانات)

🌊 شرح المصطلح

QPS (Queries Per Second): عدد الاستعلامات في الثانية، مقياس لإنتاجية النظام.

100 ألف QPS تعني 100 ألف طلب في الثانية، مثل دخول 100 ألف شخص إلى متجر في نفس اللحظة.

4.2 حل تخفيف القمم وملء الوديان: طابور الرسائل "كخزان مياه"

تصميم البنية:

┌───────────────────────────────────────────────────────────────────────┐
│                    بنية نظام البيع الخاطف                        │
├───────────────────────────────────────────────────────────────────────┤
│                                                               │
│  الطبقة الأولى: طبقة البوابة (تحديد صارم للتدفق)                    │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  - تحديد التدفق بحاوية الرموز: 100 ألف/ثانية → 10 آلاف/ثانية      │  │
│  │  - تخزين CDN للموارد الثابتة (صفحة تفاصيل المنتج)        │  │
│  │  - رمز التحقق/صفحة الانتظار (الطبقة الأولى لتخفيف القمم)     │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                            │                                 │
│                            ▼                                 │
│  الطبقة الثانية: طبقة الخدمة (تحديد مرن للتدفق)                       │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  - تحديد تدفق Nginx: 10 آلاف/ثانية → 5000/ثانية                  │  │
│  │  - خصم مسبق للمخزون عبر Redis (عملية ذرية):             │  │
│  │    * استخدام Lua script لضمان الذرية                   │  │
│  │    * نفاد المخزون يعيد مباشرة "تم البيع بالكامل"        │  │
│  │  - إنشاء رمز الطلب (إثبات الانتظار)                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                            │                                 │
│                            ▼                                 │
│  الطبقة الثالثة: طبقة طابور الرسائل (التخفيف الأساسي للقمم)                │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Kafka/RocketMQ:                                     │  │
│  │  - كتابة دفعات: 5000/ثانية → 1000/ثانية (قدرة قاعدة البيانات)  │  │
│  │  - استمرارية الرسائل: تخزين على القرص لضمان عدم فقدان الرسائل     │  │
│  │  - استهلاك متوازي متعدد الأقسام: تحسين الإنتاجية             │  │
│  │  - إدارة إزاحة الاستهلاك: دعم استعادة الأعطال                  │  │
│  │                                                       │  │
│  │  مراقبة المؤشرات الأساسية:                                │  │
│  │  - معدل الإنتاج (Produce Rate)                        │  │
│  │  - معدل الاستهلاك (Consume Rate)                       │  │
│  │  - تراكم الرسائل (Lag)                                 │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                            │                                 │
│                            ▼                                 │
│  الطبقة الرابعة: طبقة الاستهلاك (معالجة غير متزامنة)                   │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  مستهلك معالجة الطلبات (نسخ متعددة):                        │  │
│  │  - سحب الرسائل من Kafka (1000/ثانية, مطابقة لقدرة قاعدة البيانات)   │  │
│  │  - معاملة قاعدة البيانات: إنشاء الطلب + خصم المخزون            │  │
│  │  - تحديث حالة الطلب إلى "تم الإنشاء"                      │  │
│  │  - إرسال إشعار نجاح إنشاء الطلب (بريد/رسائل نصية/دفع)          │  │
│  │  - تأكيد استهلاك الرسالة (ACK)                            │  │
│  │                                                         │  │
│  │  استراتيجية توسيع المستهلكين:                               │  │
│  │  - عندما Lag > 10000, زيادة نسخ المستهلكين تلقائيًا         │  │
│  │  - عندما Lag < 1000, تقليل نسخ المستهلكين (توفير التكلفة)      │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                               │
└───────────────────────────────────────────────────────────────────────┘

Processing capacity (Consumer)200 req/s

Maximum backend processing speed

Queue capacity (Queue Size)2000

Maximum requests the message queue can buffer

Current inbound traffic

100 req/s

Queue backlog

0 msgs

Actual processing rate

0 req/s

Rejected requests (rate limited)

0 req

Inbound traffic (user requests)Processed traffic (system load)Queue backlog

💡

4.3 المبادئ الرياضية لتخفيف القمم وملء الوديان

تأثير تنعيم حركة المرور:

حركة المرور الأصلية (قمم حادة):        حركة المرور بعد التنعيم:

100ألف/ث │    ╱╲                  1000/ث │████████████████
         │   ╱  ╲                        │
         │  ╱    ╲                       │
 1000/ث  │╱        ╲                 0/ث │
         └───────────────               └────────────────
         0ث    1ث    2ث                 0ث              20ث

الأصلية: ذروة 100 ألف/ثانية، تستمر لثانية واحدة
بعد التنعيم: معدل ثابت 1000/ثانية، يستمر لمدة 100 ثانية

المعادلات الأساسية:

طول الطابور = معدل المنتج × المدة - معدل المستهلك × المدة
            = 100,000 × 1 - 1,000 × 1
            = 99,000 رسالة (تراكم الذروة في الطابور)

الوقت اللازم لاستهلاك جميع الرسائل = طول الطابور / معدل المستهلك
                                  = 99,000 / 1,000
                                  = 99 ثانية

5. السؤال الأساسي الثالث: كيف نضمن عدم فقدان الرسائل، وعدم تكرارها، وترتيبها؟

5.1 موثوقية الرسائل: ثلاثة خطوط دفاع

قد تضيع الرسائل في ثلاث مراحل: عند إرسال المنتج، عند تخزين الوسيط، عند معالجة المستهلك.

🛡️ ثلاثة خطوط دفاع

خط الدفاع 1: تأكيد المنتج (Producer ACK)

عند إرسال رسالة، انتظر تأكيد الوسيط باستلامها
إذا لم يصل التأكيد، أعد المحاولة أو سجل في السجل المحلي

خط الدفاع 2: استمرارية الوسيط (Broker Persistence)

كتابة الرسائل على القرص، وليس فقط في الذاكرة
مزامنة نسخ متعددة، لضمان عدم فقدان البيانات

خط الدفاع 3: تأكيد المستهلك (Consumer ACK)

بعد معالجة الرسالة، تأكيد يدوي (ACK)
إذا فشلت المعالجة، لا تؤكد، وسيعيد الوسيط التسليم

🛡️Message Reliability DemoThree defense lines keep messages from being lost

Line 1

Producer ACK

📤

Producer

Send message

📨

Message

✓

ACK confirmation

📦

Broker

Receive and store

Send message

💡 If no ACK is received, the producer retries or records a local log.

Line 2

Broker persistence

⚡

Memory storage

Fast, but lost on restart

❌ High risk

💾

Disk storage

Persisted to avoid loss

✅ Recommended

🔄 Multi-replica sync

Messages are synced to 3 nodes, so data is not lost even if 1 node fails.

Storage mode

✅ Message persisted and safe

Line 3

Consumer ACK

Pull message

Fetch message from Broker

→

Process message

Run business logic

→

Manual ACK

Confirm after processing

Auto ACK

Efficient but can lose messages

⚠️ Not recommended

Manual ACK

Reliable, ACK after processing

✅ Recommended

Simulate consumption

💡 If processing fails, no ACK is sent and the Broker redelivers.

🎯

All three defense lines are required:Producer ACK → Broker persistence → Consumer ACK

5.2 كيف نتعامل مع استهلاك الرسائل المكرر؟

قد يحدث تكرار الرسائل في السيناريوهات التالية:

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

💡 اللامتغيرية (Idempotence)

اللامتغيرية: تنفيذ نفس العملية عدة مرات يعطي نفس نتيجة تنفيذها مرة واحدة.

اللامتغيرية في الحياة اليومية:

لامتغيري: الضغط على زر المصعد (الضغط 10 مرات أو مرة واحدة، سيأتي المصعد في كل الأحوال)
غير لامتغيري: التحويل البنكي (تحويل 10 يوان، تنفيذه مرتين يحول 20 يوان)

الحل التقني: إنشاء معرف فريد لكل رسالة، والتحقق قبل المعالجة مما إذا تمت معالجتها مسبقًا.

🔄Idempotence DemoRepeated consumption does not create side effects

❌ Non-idempotent operation: bank transfer

Repeated consumption can debit multiple times

Sender

Balance: ¥1000

💰

Transfer ¥100

Receiver

Balance: ¥500

Idempotence protection

Disabled

Processing log

No logs yet. Click the button to start.

❌ No idempotence protection

Debit ¥100

Duplicate consumption causes multiple debits

✅ With idempotence protection

Debit ¥100

Duplicate requests are filtered, so debit happens once

🎯

Core idempotence principle: Generate a unique ID for each message and check whether it was processed before doing the operation.

6. تطبيق عملي: كيف نختار طابور الرسائل؟

6.1 مقارنة بين أربعة طوابير رسائل رئيسية

الميزة	RabbitMQ	Kafka	RocketMQ	Redis Stream
الموقع	طابور رسائل تقليدي	سجل توزيع موزع	طابور رسائل للتجارة الإلكترونية	طابور خفيف الوزن
الإنتاجية	~10 آلاف/ثانية	~1 مليون/ثانية	~100 ألف/ثانية	~50 ألف/ثانية
زمن الانتقال	ميكروثانية	ملي ثانية	ملي ثانية	ملي ثانية
الموثوقية	عالية (استمرارية)	عالية (نسخ متعددة)	عالية (كتابة متزامنة على القرص)	متوسطة (AOF)
استرجاع الرسائل	غير مدعوم	مدعوم	مدعوم	مدعوم
رسائل المعاملات	مدعوم (ضعيف)	غير مدعوم	مدعوم (قوي)	غير مدعوم
الرسائل المؤجلة	مدعوم	غير مدعوم	مدعوم	غير مدعوم
السيناريوهات المناسبة	تطبيقات المؤسسات التقليدية	السجلات، البيانات الكبيرة	التجارة الإلكترونية، المالية	تطبيقات صغيرة النطاق

💡 توصيات الاختيار

شجرة القرار:

اختيار طابور الرسائل:
│
├─ تحتاج رسائل معاملات (معاملات موزعة)؟
│  ├─ نعم → RocketMQ (الخيار الأول) أو RabbitMQ
│  └─ لا → تابع
│
├─ تحتاج معالجة سجلات هائلة/تدفق فوري؟
│  ├─ نعم → Kafka (الخيار الأول)
│  └─ لا → تابع
│
├─ QPS > 10 آلاف/ثانية؟
│  ├─ نعم → RocketMQ أو Kafka
│  └─ لا → تابع
│
├─ تحتاج توجيه معقد (مثل مطابقة headers)؟
│  ├─ نعم → RabbitMQ
│  └─ لا → تابع
│
├─ لديك بنية Redis مسبقًا؟
│  ├─ نعم → Redis Stream (بداية سريعة)
│  └─ لا → RabbitMQ (وظائف شاملة، منحنى تعلم معتدل)

7. ملخص: خلاصة تصميم طوابير الرسائل

7.1 مراجعة المبادئ الأساسية

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

7.2 قائمة مراجعة التصميم

قبل إدخال طابور الرسائل، اسأل نفسك الأسئلة التالية:

[ ] هل تحتاج حقًا إلى طابور رسائل؟ (يمكن استخدام تجمع الخيوط للمهام غير المتزامنة البسيطة)
[ ] هل فقدان الرسائل مقبول؟ (يحدد مستوى الموثوقية)
[ ] هل تكرار الرسائل سيؤثر على الأعمال؟ (يحدد الاستثمار في اللامتغيرية)
[ ] هل ترتيب الرسائل مهم؟ (يحدد استراتيجية التقسيم)
[ ] ما هي قدرة معالجة المستهلك؟ (يحدد حجم الطابور وحدود الإنذار)
[ ] كيف نعالج فشل الاستهلاك؟ (يحدد استراتيجية إعادة المحاولة والرسائل الميتة)

8. جدول المصطلحات المرجعي

المصطلح	الاسم الكامل	الشرح
MQ	Message Queue	طابور الرسائل. وسيط للاتصال غير المتزامن، يحقق فصل الاقتران بين المنتج والمستهلك.
Producer	-	المنتج. الطرف الذي يرسل الرسائل.
Consumer	-	المستهلك. الطرف الذي يستقبل الرسائل ويعالجها.
Broker	-	وسيط الرسائل. برنامج الخادم الذي يخزن الرسائل ويعيد توجيهها.
Topic	-	الموضوع. التصنيف المنطقي للرسائل (مثل "orders").
Queue	-	الطابور. الحاوية الفعلية لتخزين الرسائل.
Partition	-	القسم. مفهوم في Kafka، يمكن تقسيم Topic إلى عدة Partitions، لتحسين التزامن.
ACK	Acknowledgment	التأكيد. بعد معالجة المستهلك للرسالة، يؤكد للوسيط.
Pub/Sub	Publish/Subscribe	النشر والاشتراك. نمط رسائل حيث يمكن استقبال الرسالة الواحدة من قبل عدة مستهلكين.
P2P	Point-to-Point	نقطة إلى نقطة. نمط رسائل حيث يمكن استقبال الرسالة الواحدة من قبل مستهلك واحد فقط.
DLQ	Dead Letter Queue	طابور الرسائل الميتة. يخزن الرسائل التي لا يمكن استهلاكها.
Idempotence	-	اللامتغيرية. تنفيذ العملية عدة مرات يعطي نفس النتيجة.
Throughput	-	الإنتاجية. عدد الرسائل المعالجة في وحدة الزمن.
Latency	-	زمن الانتقال. الفارق الزمني بين إرسال الرسالة واستقبالها.
Persistence	-	الاستمرارية. كتابة الرسائل على القرص، وليس فقط في الذاكرة.
Replication	-	النسخ. من أجل التوفر العالي، تُنسخ الرسائل إلى عقد متعددة.
Transaction Message	-	رسالة المعاملة. تضمن اتساق المعاملة المحلية مع إرسال الرسالة.
Backpressure	-	الضغط الخلفي. عندما لا يستطيع المستهلك المواكبة، يُخطر المنتج بتقليل السرعة.
Offset	-	الإزاحة. موقع استهلاك المستهلك في القسم.
Rebalance	-	إعادة التوازن. عند تغير أعضاء مجموعة المستهلكين، إعادة توزيع الأقسام.

طوابير الرسائل والبنية المدفوعة بالأحداث ​

1. لماذا نحتاج إلى "طوابير الرسائل"؟ ​

1.1 قصة من الواقع: تطور نظام الطلبات في تاوباو ​

1.2 تشبيه طوابير الرسائل من الحياة اليومية ​

2. ما هو طابور الرسائل؟ (التعريف + العناصر الأساسية الثلاثة) ​

2.1 ما هو "طابور الرسائل"؟ ​

2.2 العناصر الأساسية الثلاثة لطابور الرسائل ​

العنصر الأول: المنتج (Producer) ​

العنصر الثاني: المستهلك (Consumer) ​

العنصر الثالث: الوسيط (Broker) ​

3. السؤال الأساسي الأول: كيف نفصل اقتران النظام لتجنب "تحريك خيط واحد يحرك الكل"؟ ​

3.1 مأساة الاقتران المحكم: تعطل خدمة واحدة يؤدي لانهيار الكل ​

3.2 حل فصل الاقتران: إدخال طابور الرسائل "كطبقة وسيطة" ​

3.3 جوهر فصل الاقتران: من "الاستدعاء المباشر" إلى "البنية المدفوعة بالأحداث" ​

4. السؤال الأساسي الثاني: كيف نخفف القمم ونملأ الوديان لمواجهة ارتفاعات حركة المرور؟ ​

4.1 سيناريو البيع الخاطف: كيف نعالج 100 ألف QPS بسلاسة؟ ​

4.2 حل تخفيف القمم وملء الوديان: طابور الرسائل "كخزان مياه" ​

4.3 المبادئ الرياضية لتخفيف القمم وملء الوديان ​

5. السؤال الأساسي الثالث: كيف نضمن عدم فقدان الرسائل، وعدم تكرارها، وترتيبها؟ ​

5.1 موثوقية الرسائل: ثلاثة خطوط دفاع ​

5.2 كيف نتعامل مع استهلاك الرسائل المكرر؟ ​

6. تطبيق عملي: كيف نختار طابور الرسائل؟ ​

6.1 مقارنة بين أربعة طوابير رسائل رئيسية ​

7. ملخص: خلاصة تصميم طوابير الرسائل ​

7.1 مراجعة المبادئ الأساسية ​

7.2 قائمة مراجعة التصميم ​

8. جدول المصطلحات المرجعي ​

طوابير الرسائل والبنية المدفوعة بالأحداث

1. لماذا نحتاج إلى "طوابير الرسائل"؟

1.1 قصة من الواقع: تطور نظام الطلبات في تاوباو

1.2 تشبيه طوابير الرسائل من الحياة اليومية

2. ما هو طابور الرسائل؟ (التعريف + العناصر الأساسية الثلاثة)

2.1 ما هو "طابور الرسائل"؟

2.2 العناصر الأساسية الثلاثة لطابور الرسائل

العنصر الأول: المنتج (Producer)

العنصر الثاني: المستهلك (Consumer)

العنصر الثالث: الوسيط (Broker)

3. السؤال الأساسي الأول: كيف نفصل اقتران النظام لتجنب "تحريك خيط واحد يحرك الكل"؟

3.1 مأساة الاقتران المحكم: تعطل خدمة واحدة يؤدي لانهيار الكل

3.2 حل فصل الاقتران: إدخال طابور الرسائل "كطبقة وسيطة"

3.3 جوهر فصل الاقتران: من "الاستدعاء المباشر" إلى "البنية المدفوعة بالأحداث"

4. السؤال الأساسي الثاني: كيف نخفف القمم ونملأ الوديان لمواجهة ارتفاعات حركة المرور؟

4.1 سيناريو البيع الخاطف: كيف نعالج 100 ألف QPS بسلاسة؟

4.2 حل تخفيف القمم وملء الوديان: طابور الرسائل "كخزان مياه"

4.3 المبادئ الرياضية لتخفيف القمم وملء الوديان

5. السؤال الأساسي الثالث: كيف نضمن عدم فقدان الرسائل، وعدم تكرارها، وترتيبها؟

5.1 موثوقية الرسائل: ثلاثة خطوط دفاع

5.2 كيف نتعامل مع استهلاك الرسائل المكرر؟

6. تطبيق عملي: كيف نختار طابور الرسائل؟

6.1 مقارنة بين أربعة طوابير رسائل رئيسية

7. ملخص: خلاصة تصميم طوابير الرسائل

7.1 مراجعة المبادئ الأساسية

7.2 قائمة مراجعة التصميم

8. جدول المصطلحات المرجعي