Redis Pipelining بالعربي: 1000 طلب في رحلة شبكة واحدة

وبعدين الكود الفعلي اللي بيقيس الفرق:

لاحظ transaction=False. لو سبتها True (الـ default في redis-py)، الـ client هيلفّ الـ pipeline في MULTI/EXEC وهتخسر شوية من المكسب لأن السيرفر بيتعامل معاهم بشكل atomic.

الأرقام الحقيقية على سيرفر فعلي

القياس على Redis 7.2 محلي على macOS، Python 3.11، redis-py 5.0.1، 1000 أمر SET بمفاتيح وقيم قصيرة (أقل من 50 بايت). الأرقام دي تقديرية تمثّل الـ order of magnitude — هتلاقي تباين 10-20% حسب جهازك:

• بدون pipelining (localhost، RTT ≈ 0.05ms): ~4,180ms
• مع pipelining: ~78ms
• التحسّن: ~53x أسرع

على شبكة متوسطة بين application server وRedis في نفس المنطقة (RTT ≈ 2ms):

• بدون pipelining: ~6,500ms
• مع pipelining: ~120ms
• التحسّن: ~54x

الافتراض المهم هنا: الأرقام دي على أوامر بسيطة بقيم صغيرة. لو القيم الواحدة 50KB، الـ bandwidth بيبقى الـ bottleneck بدل الـ latency، والمكسب بينزل لـ 5-10x. المهارة الحقيقية إنك تعرف أنهي حالة عندك.

trade-offs لازم تعرفها قبل ما تستخدمها

كل تحسين له ثمن. Pipelining مش مجاني:

• استهلاك ذاكرة على الـ client: الأوامر بتتجمّع في buffer لحد ما execute(). لو عندك مليون أمر في pipeline واحد، الـ Python process ممكن يتورّم لـ مئات الـ MBs. الحل: قسّم على batches من 1,000 إلى 10,000 أمر.
• طول الـ output buffer على السيرفر: Redis بيخزن الردود في buffer قبل ما يبعتها. batch ضخم جدًا ممكن يتعدى client-output-buffer-limit ويخلي السيرفر يقفل الاتصال.
• مفيش atomicity: لو فشل الأمر رقم 50 من 100، الـ 49 اللي قبله نفّذوا فعلًا. لو محتاج كل أوامرك ينجحوا أو يفشلوا سوا، استخدم MULTI/EXEC أو Lua script.
• صعوبة الديباجينج: الردود بتيجي دفعة واحدة، تتبّع أمر معيّن فشل بقى أصعب من الـ logging العادي. لازم تتعامل مع الـ list اللي راجعة من pipe.execute() بترتيب الأوامر.

متى لا تستخدم Pipelining

الطريقة دي مش حل لكل حالة. ابعد عنها لو:

• كل أمر يعتمد على نتيجة اللي قبله: مثلًا تعمل GET، تعدّل القيمة في Python، تعمل SET. هنا Pipelining بيكسر السيناريو لأنك بتبعت SET قبل ما تستلم GET. استخدم Lua script أو WATCH/MULTI/EXEC.
• عدد الأوامر صغير (أقل من 5): الـ overhead الإضافي لإنشاء الـ pipeline بيلغي مكسبه.
• محتاج atomicity صارمة: Lua scripts أنسب.
• الأمر الواحد بيرجع رد ضخم: زي LRANGE 0 -1 على list فيه مليون عنصر. هنا الـ bandwidth هو المشكلة، مش الـ latency، وPipelining مش هيحل حاجة.
• عندك أمر MGET أو MSET متاح بدلًا منه: لو كل اللي عايزه تجيب 100 مفتاح بـ GET، استخدم MGET مباشرة — أبسط وأنضف من Pipelining.

متى تستخدمه فعلًا (السيناريوهات الواقعية)

• تهجير 100K مفتاح من قاعدة لتانية (data migration scripts).
• تخزين mass batch من sessions أو cache entries عند بدء التشغيل (warm-up).
• قراءة عدة مفاتيح مستقلة عن بعضها بـ commands مختلفة (HGET + ZSCORE + GET في نفس الـ logic).
• writes متفرقة في endpoint بيستقبل bulk data من webhook أو import.
• أي logic بيعمل أكتر من 50 أمر Redis في request واحد.

الخطوة التالية

افتح أي script Redis عندك بيدخل في loop ويعمل أكتر من 50 أمر. لفّ الـ loop داخل r.pipeline(transaction=False) وشغّله مع time.time() قبل وبعد. لو الفرق أقل من 5x، ده معناه إن الـ latency مش هي الـ bottleneck — غالبًا المشكلة في حجم الردود أو CPU. لو 30x فأكتر، Pipelining هو اللي كنت محتاجه فعلًا.

مصادر

• Redis Documentation — Using pipelining to speedup Redis queries: redis.io/docs/latest/develop/use/pipelining
• redis-py Documentation — Pipelines: redis.readthedocs.io/en/stable/connections.html
• Redis Benchmarking Guide: redis.io/docs/latest/operate/oss_and_stack/management/optimization/benchmarks
• Redis Configuration — client-output-buffer-limit: redis.io/docs/latest/operate/oss_and_stack/management/config
• Redis Transactions vs Pipelining: redis.io/docs/latest/develop/interact/transactions