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

مستوى المقال: متوسط — يفترض إنك مستخدم Redis قبل كده وعارف أوامر زي SET / GET / MGET، لكن مش لازم تكون عملت optimization جدي قبل كده.

لو تطبيقك بيعمل 1000 طلب SET على Redis في loop وبياخد 4 ثواني، Redis نفسه مش هو المشكلة. كل أمر بيستنى رد كامل عبر الشبكة قبل ما اللي بعده يتبعت. Pipelining بينزّل الزمن ده لـ 80ms على نفس السيرفر بدون تغيير كود الـ business، وده اللي هنفصّله بالظبط.

المشكلة باختصار

Redis سريع جدًا داخليًا. الأمر الواحد بياخد جزء من الميكروثانية على السيرفر نفسه. لكن بين كل أمر وأمر فيه latency شبكة. لو السيرفر والتطبيق على نفس الـ data center، الـ RTT (round-trip time) حوالي 0.4ms. لو على Cloud مختلفة أو بين منطقتين، ممكن يوصل 4ms أو أكتر.

اعمل الحسبة: 1000 أمر × 0.5ms انتظار = 500ms ضائعين على الشبكة، حتى لو Redis نفسه عمل الـ 1000 عملية في 5ms. المشكلة كلها في فكرة "إبعت أمر، استنى الرد، بعدين إبعت اللي بعده".

المثال البسيط: زيارة السوبر ماركت

تخيّل عايز تشتري 100 منتج من سوبر ماركت. عندك طريقتين:

• الطريقة الغلط: تروح، تشتري منتج واحد، تدفع، تخرج، ترجع، تشتري التاني، تدفع، تخرج. 100 مرة. كل مرة بتستنى دور الكاشير وبتمشي على القدم. الزمن الإجمالي = (دقيقة للطابور + دقيقة للمشي) × 100 = 200 دقيقة.
• الطريقة الصح: تحط الـ 100 منتج في عربية واحدة، تروح للكاشير مرة واحدة، يحسبهم كلهم، تخرج. زمن الطابور حصل مرة واحدة بدل 100 مرة. الإجمالي = 5 دقائق.

Pipelining في Redis هو نفس فكرة العربية الواحدة. بدل ما الـ client يبعت أمر ويستنى الرد قبل التالي، بيلمّ مجموعة أوامر مع بعض، يبعتهم في طلب شبكة واحد، ويستقبل الردود كلها سوا.

التعريف العلمي الدقيق

Pipelining هو إرسال مجموعة أوامر متتالية على نفس الـ TCP connection بدون انتظار الرد على كل أمر قبل إرسال اللي بعده. الأوامر بتتراص في buffer العميل، تتبعت دفعة واحدة، والسيرفر بيرجّع كل الردود في buffer واحد. التقنية موجودة في Redis من إصدار 1.0 وموثّقة في "Using pipelining to speedup Redis queries" على الـ docs الرسمية.

فيه فرق مهم بين 3 مفاهيم بيتلخبطوا في بعض، ركّز:

• Pipelining: توفير latency الشبكة فقط. الأوامر مش atomic — ممكن يدخل بينهم أوامر من client تاني.
• MULTI/EXEC (Transactions): الأوامر atomic لكن ما بتقللش latency لو الـ client بيستنى رد قبل ما يبعت EXEC.
• Lua Scripts (EVAL): الأوامر atomic + بتنفّذ كلها على السيرفر، بدون أي round-trip بين كل أمر.

الـ Pipelining بيتعامل مع أعراض الـ network round-trip بس. لو محتاج atomicity حقيقية، خد قرار تاني.

الحل العملي بكود Python شغّال

الكود ده مكتوب على redis-py 5.0.1 وRedis 7.2. شغّل الـ server محليًا أو على Docker قبل ما تجرّب:

docker run -d --name redis-test -p 6379:6379 redis:7.2-alpine

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

import redis
import time

r = redis.Redis(host='localhost', port=6379, db=0)
r.flushdb()

# الطريقة البطيئة: 1000 طلب منفصل
start = time.time()
for i in range(1000):
    r.set(f'key:{i}', f'value:{i}')
elapsed_normal = (time.time() - start) * 1000
print(f'بدون pipelining: {elapsed_normal:.0f}ms')

# الطريقة السريعة: 1000 أمر في pipeline واحد
r.flushdb()
start = time.time()
pipe = r.pipeline(transaction=False)
for i in range(1000):
    pipe.set(f'key:{i}', f'value:{i}')
pipe.execute()
elapsed_pipe = (time.time() - start) * 1000
print(f'مع pipelining:  {elapsed_pipe:.0f}ms')
print(f'تحسّن: {elapsed_normal / elapsed_pipe:.1f}x')

لاحظ 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