كانت عمليات الإطلاق تغرق خوادمنا: كيف أنقذنا “طابور الانتظار الافتراضي” من جحيم انهيار الخدمة؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.

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

الساعة 12:00 منتصف الليل، موعد الإطلاق. انبعتت رسائل البريد الإلكتروني والرسائل النصية للمستخدمين. وفي أقل من دقيقة، اللي صار مش طبيعي. شاشات المراقبة اللي كانت خضرا ومريحة للعين، صارت حمرا زي الفلفل الشطّة. معالجات الخوادم (CPU) وصلت 100%، الذاكرة امتلأت، وقاعدة البيانات بلشت تصرخ وتستنجد. الموقع صار أبطأ من سلحفاة مصابة بالزكام، وبعدها… انهار بالكامل. 503 Service Unavailable.

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

لماذا تنهار الخوادم أصلاً؟ مشكلة “القطيع الهادر”

قبل ما نحكي عن الحل، لازم نفهم أصل المشكلة. المشكلة اللي واجهناها الها اسم تقني مشهور: مشكلة القطيع الهادر (Thundering Herd Problem).

تخيل معي عندك مخبز (هو تطبيقك) بيقدر يخدم 10 زباين في الدقيقة بشكل مريح. فجأة، وبسبب إعلان عن خبز مجاني، بيوصل 1000 زبون للمخبز في نفس اللحظة. شو راح يصير؟

• تدافع على الباب (الـ Load Balancer).
• الخبّاز (الـ Application Server) راح يرتبك ومش راح يعرف يخدم مين ولا مين.
• الفرن (قاعدة البيانات) راح توصل أقصى درجة حرارة وممكن تتعطل.

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

محاولات فاشلة (أو غير كافية) لحل المشكلة

طبعاً أول شي بيخطر في بال أي مطور هو:

1. التوسع الأفقي (Horizontal Scaling): “زيد عدد الخوادم يا أبو عمر!”. نعم، هذا حل جيد ومهم، لكنه مكلف جداً لمواجهة ذروة تحدث مرة أو مرتين في السنة. هل من المنطقي أن تدفع إيجار 100 خادم طول السنة وأنت لا تحتاجهم إلا ليوم واحد؟ بالإضافة إلى أن بعض أجزاء النظام (مثل قاعدة البيانات) لا تتوسع أفقيًا بسهولة.
2. التوسع العامودي (Vertical Scaling): “نجيب خادم أكبر وأقوى!”. هذا الحل له سقف. هناك حد فيزيائي لقوة الخادم الواحد، وبعدها تصبح التكلفة فلكية، وأنت لا تزال عرضة لنفس المشكلة إذا تجاوز الحمل قدرة هذا الخادم العملاق.

هذه الحلول مثل توسيع باب المخبز، لكنها لا تنظم دخول الزبائن. المشكلة في “التدفق” وليس فقط في “السعة”.

الحل المنقذ: طابور الانتظار الافتراضي

هنا يأتي دور بطل قصتنا. طابور الانتظار الافتراضي هو ببساطة “غرفة انتظار” رقمية نضع فيها المستخدمين قبل دخولهم إلى التطبيق الرئيسي. الفكرة هي تحويل الفوضى (القطيع الهادر) إلى نظام (طابور منظم).

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

كيف يعمل الطابور الافتراضي من الناحية المعمارية؟

المعمارية بسيطة لكنها فعالة جداً، وتتكون من عدة أجزاء رئيسية:

1. نقطة الدخول (Entry Point): عندما يحاول المستخدم الوصول لموقعك، يتم تحويله أولاً إلى خدمة الطابور (Queue Service). هذه الخدمة يجب أن تكون خفيفة وسريعة وقادرة على تحمل عدد هائل من الاتصالات المتزامنة.
2. منطق القرار (The Gatekeeper): هذه الخدمة تتحقق من “صحة” التطبيق الرئيسي. هل هناك سعة متاحة؟ إذا كانت الإجابة “نعم”، يتم تحويل المستخدم مباشرة إلى التطبيق. إذا كانت الإجابة “لا”، يتم وضعه في الطابور.
3. صفحة الانتظار (Waiting Room Page): إذا تم وضع المستخدم في الطابور، يتم عرض صفحة بسيطة له تخبره بأنه في قائمة الانتظار، وتعرض له معلومات مثل: موقعه في الطابور، والوقت المتوقع للانتظار. هذه الصفحة تتحدث مع خدمة الطابور بشكل دوري لتحديث حالتها.
4. مدير الطابور (Queue Manager): هو القلب النابض للنظام. عادةً ما يكون قاعدة بيانات سريعة في الذاكرة (In-memory) مثل Redis. هو المسؤول عن تخزين هويات المستخدمين في الطابور والحفاظ على ترتيبهم.
5. المُمرِّر (The Conductor): هو عملية في الخلفية (Background Process) تعمل بشكل مستمر. كل بضع ثوانٍ، تتحقق من صحة التطبيق الرئيسي، وإذا كان بإمكانه استقبال المزيد من المستخدمين، تقوم “بسحب” عدد معين من المستخدمين من بداية الطابور (من Redis) وتسمح لهم بالمرور.

مثال عملي مبسط باستخدام Node.js و Redis

لتقريب الصورة، دعونا نرى كيف يمكن بناء نسخة مصغرة جداً من هذا النظام. سنستخدم Node.js (مع Express) لخدمة الويب، وRedis لإدارة الطابور.

الجزء الأول: إضافة المستخدمين إلى الطابور

سنستخدم Redis Sorted Set. الميزة هنا أننا نستطيع ترتيب المستخدمين حسب وقت دخولهم (الـ score سيكون timestamp الدخول).

// Middleware to handle queue logic
const redisClient = require('./redisClient');
const MAX_ACTIVE_USERS = 100; // أقصى عدد مستخدمين في التطبيق بنفس الوقت
const WAITING_ROOM_KEY = 'waiting_room';
const ACTIVE_USERS_KEY = 'active_users';

async function queueMiddleware(req, res, next) {
    const userId = req.cookies.userId || generateUserId(); // افترض وجود ID لكل مستخدم
    res.cookie('userId', userId, { maxAge: 900000, httpOnly: true });

    const isActive = await redisClient.sIsMember(ACTIVE_USERS_KEY, userId);
    if (isActive) {
        // المستخدم نشط بالفعل، دعه يمر
        return next();
    }

    const activeUsersCount = await redisClient.sCard(ACTIVE_USERS_KEY);

    if (activeUsersCount < MAX_ACTIVE_USERS) {
        // هناك سعة، أضف المستخدم للنشطين ودعه يمر
        await redisClient.sAdd(ACTIVE_USERS_KEY, userId);
        // Set an expiry for the user's active session
        await redisClient.expire(ACTIVE_USERS_KEY + ':' + userId, 300); // 5 minutes activity
        return next();
    } else {
        // لا يوجد سعة، أضف المستخدم لغرفة الانتظار
        const entryTime = Date.now();
        await redisClient.zAdd(WAITING_ROOM_KEY, { score: entryTime, value: userId });
        
        // اعرض صفحة الانتظار
        res.status(200).render('waiting-room', { userId });
    }
}

الجزء الثاني: المُمرِّر (The Conductor)

هذا مجرد سكربت يعمل في الخلفية ويسمح للمستخدمين بالدخول على دفعات.

// conductor.js - Runs as a background process
const redisClient = require('./redisClient');
const MAX_ACTIVE_USERS = 100;
const USERS_TO_ADMIT_PER_TICK = 10; // عدد المستخدمين المسموح بدخولهم كل مرة

async function runConductor() {
    try {
        // أولاً، قم بتنظيف المستخدمين غير النشطين
        // (This logic can be complex, e.g., using a separate cleanup script)

        const activeUsersCount = await redisClient.sCard(ACTIVE_USERS_KEY);
        const availableSlots = MAX_ACTIVE_USERS - activeUsersCount;

        if (availableSlots > 0) {
            const usersToAdmit = Math.min(availableSlots, USERS_TO_ADMIT_PER_TICK);
            
            // اسحب أقدم المستخدمين من طابور الانتظار
            const waitingUsers = await redisClient.zPopMin(WAITING_ROOM_KEY, usersToAdmit);

            if (waitingUsers && waitingUsers.length > 0) {
                const userIds = waitingUsers.map(user => user.value);
                console.log(`Admitting ${userIds.length} new users:`, userIds);
                
                // أضفهم إلى مجموعة المستخدمين النشطين
                await redisClient.sAdd(ACTIVE_USERS_KEY, userIds);
            }
        }
    } catch (err) {
        console.error('Conductor error:', err);
    }
}

// شغل الـ conductor كل 5 ثواني
setInterval(runConductor, 5000);

الجزء الثالث: التحقق من حالة المستخدم في الطابور

تحتاج صفحة الانتظار إلى endpoint تستدعيه لمعرفة ترتيبها.

// API endpoint for the waiting room page to poll
app.get('/queue/status', async (req, res) => {
    const { userId } = req.cookies;
    if (!userId) {
        return res.status(400).json({ error: 'No user ID found' });
    }

    // هل تم السماح لي بالدخول؟
    const isActive = await redisClient.sIsMember(ACTIVE_USERS_KEY, userId);
    if (isActive) {
        return res.json({ status: 'admitted' });
    }

    // إذا لم يتم، ما هو ترتيبي في الطابور؟
    const rank = await redisClient.zRank(WAITING_ROOM_KEY, userId);

    if (rank !== null) {
        const totalInQueue = await redisClient.zCard(WAITING_ROOM_KEY);
        res.json({
            status: 'waiting',
            position: rank + 1,
            total: totalInQueue
        });
    } else {
        // قد يكون المستخدم قد خرج من الطابور ولكن لم يتم تحديث الكوكيز بعد
        res.json({ status: 'admitted' });
    }
});

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

نصائح أبو عمر الذهبية (من واقع الخبرة)

• تجربة المستخدم في غرفة الانتظار هي الأهم: لا تترك المستخدم أمام شاشة بيضاء. أعطه معلومات واضحة: “أنت رقم 500 في الطابور، الوقت المتوقع للانتظار هو 5 دقائق”. استخدم شريط تقدم (progress bar). الأهم من ذلك، طمئن المستخدم أن مكانه محفوظ وأنه لا يجب عليه تحديث الصفحة بشكل يدوي.
• اجعل “البوابة” ذكية: الرقم MAX_ACTIVE_USERS لا يجب أن يكون ثابتًا. أفضل الأنظمة تجعل هذا الرقم ديناميكيًا بناءً على مؤشرات حيوية حقيقية من التطبيق الرئيسي (CPU Load, DB Connections, API Response Time). إذا كانت صحة التطبيق جيدة، اسمح بدخول المزيد، والعكس صحيح.
• لا تبنِ العجلة من جديد (إلا إذا كان يجب عليك): هناك خدمات جاهزة تقدم هذه الوظيفة مثل Queue-it و حلول من AWS. إذا كان لديك الوقت والموارد المحدودة، استخدام خدمة جاهزة هو خيار ممتاز. لكن فهم المبادئ الأساسية سيساعدك على استخدامها بشكل أفضل أو بناء نسختك الخاصة عند الحاجة.
• اختبر، ثم اختبر، ثم اختبر: قبل يوم الإطلاق، قم بعمل محاكاة حقيقية. استخدم أدوات اختبار الحمل (Load Testing) مثل k6, JMeter, أو Gatling لإرسال آلاف الطلبات الوهمية وتأكد من أن نظام الطابور يعمل كما هو متوقع. لا تنتظر يوم الإطلاق لتكتشف نقاط الضعف.

الخلاصة: من الفوضى إلى النظام

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

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

الآن، في ليالي الإطلاق، لا زلنا نشرب القهوة، ولكن ليس بسبب التوتر، بل للاستمتاع بمشاهدة الطابور وهو ينظم آلاف المستخدمين بسلاسة وهدوء. وهذا شعور لا يقدر بثمن. 👍