Redis · RabbitMQ · Indexingشرح وسيناريوهات.
التقنيات الثلاثة اللي المُقابِل بيهتم بيها. لكل واحدة: شرح مركّز (إزاي شغّالة وليه)، وبعده سيناريوهات سؤال-وجواب عملية. عشان تكون جاهز لأي زاوية.
في Magento 2، الـ Redis بيتستخدم للـ cache والـ sessions عشان يقلّل الضغط على قاعدة البيانات، والـ RabbitMQ بيشغّل المهام التقيلة في الخلفية عن طريق queues بدل ما العميل يستنّى، والـ Indexing بيجهّز جداول قراءة سريعة. الدرس بيشرح كل تقنية منهم وسيناريوهات عملية زي الـ sessions الضايعة والرسائل المكرّرة.
مخزن بيانات in-memory. في Magento بيستخدم للـ cache والـ sessions.
الـ Redis مخزن بيانات in-memory (في الرام مش الهارد). عشان كده سريع جدًا — القراءة والكتابة بتحصل في أجزاء من الميلي ثانية.
بيخزّن البيانات كـ key-value في الذاكرة. لما Magento يحتاج بيانات (config، block مترندر، session)، بيشوف Redis الأول. لو لاقاها (cache hit) بيرجّعها فورًا. لو ملقاهاش (cache miss) بيحسبها، يخزّنها في Redis، ويرجّعها.
Magento بيعمل حسابات تقيلة كتير (blocks، config، translations). بدل ما يعيدها كل مرة، بيخزّن النتيجة في Redis. وكمان بيخزّن الـ sessions فيه عشان أي سيرفر يقدر يخدم أي مستخدم (مهم للـ horizontal scaling).
- Default cache — config، blocks، layouts، الخ.
- Session storage — جلسات المستخدمين.
- Page cache — ممكن كبديل لـ Varnish (بس Varnish أفضل للصفحات).
الموقع بطيء، ولاحظت إن الـ database بتتحمّل استعلامات كتير متكرّرة لنفس البيانات (config، معلومات المتجر). إزاي تخفّف؟
أتأكد إن Redis مفعّل كـ cache backend. البيانات المتكرّرة هتتخزّن في الذاكرة، فبدل ما كل طلب يضرب الـ DB، بيتقري من Redis. ده بيقلّل الحمل على الـ DB بشكل كبير ويسرّع الاستجابة.
لأن المشكلة قراءات متكرّرة لنفس البيانات — ده بالظبط اللي الـ cache بيحلّه. Redis بيحفظ النتيجة في الرام فمفيش داعي يرجع للـ DB كل مرة.
وسّعت لـ 3 web servers ورا load balancer. بس المستخدمين بيشتكوا إنهم بيتسجّلوا خروج فجأة أو السلة بتضيع. إيه المشكلة؟
المشكلة إن الـ sessions متخزّنة محليًا على كل سيرفر. لما الـ load balancer يوجّه المستخدم لسيرفر تاني، السيرفر ده ملوش session بتاعه. الحل: خزّن الـ sessions في Redis مشترك — كل السيرفرات بتقرا من نفس المكان.
عشان الـ horizontal scaling يحتاج الـ services تكون stateless — الحالة (session) لازم في مخزن مشترك، مش محليًا. Redis بيوفّر المخزن المشترك السريع ده.
نظام رسائل (message broker). في Magento أساس المعالجة غير المتزامنة (async).
الـ RabbitMQ هو message broker — وسيط بينقل الرسائل بين الأجزاء. بيسمح إن جزء يبعت "مهمة" وجزء تاني ينفّذها لاحقًا وفي الخلفية، بدون ما الأول يستنى.
فيه Publisher (بيحط رسالة في الـ queue)، والـ Queue (طابور بيستنى فيه الرسائل)، وConsumer (بياخد الرسائل وينفّذها). الـ publisher مبيستناش النتيجة — بيحط الرسالة ويكمّل شغله.
عشان العمليات البطيئة أو التقيلة متعطّلش المستخدم. مثلًا: إرسال إيميل، تحديث نظام خارجي، معالجة import كبير. الـ publisher بيحط المهمة في الـ queue، والمستخدم بيكمّل، والـ consumer بينفّذها في الخلفية.
- Async operations — عمليات مش لازم تحصل فورًا.
- Bulk operations — معالجة كميات كبيرة على دفعات.
- Integrations — إرسال بيانات لأنظمة خارجية (ERP, PIM).
- Decoupling — فصل الأجزاء عن بعض.
كل ما order يتعمل، لازم تبعت بياناته لنظام ERP خارجي. بس ده بيبطّئ الـ checkout، ولو الـ ERP وقع الـ checkout بيفشل. الحل؟
بدل ما أبعت للـ ERP مباشرة وقت الـ checkout، أحط رسالة في RabbitMQ. الـ order بيكمّل فورًا، وconsumer بياخد الرسالة ويبعت للـ ERP في الخلفية. لو الـ ERP وقع، الرسالة بتفضل في الـ queue وتتنفّذ لما يرجع.
عشان تفصل الـ checkout عن الـ ERP. الـ checkout مايستناش عملية بطيئة، ومايعتمدش على توفّر نظام خارجي. الـ queue بيضمن إن الرسالة متضيعش حتى لو الـ ERP مؤقتًا مش متاح.
لاحظت إن بعض الرسائل بتتنفّذ مرتين (العميل اتبعتله إيميلين، أو اتخصم مرتين). ليه بيحصل وإزاي تمنعه؟
ده بيحصل لو الـ consumer نفّذ الرسالة بس وقع قبل ما يأكّد استلامها (ack)، فالـ queue بيعيد إرسالها. الحل: Idempotency — أصمّم الـ consumer إنه لو استقبل نفس الرسالة تاني، ميكرّرش التنفيذ. باستخدام مفتاح فريد لكل عملية أشيك عليه.
لأن في الأنظمة الموزّعة، التكرار وارد (retries، أعطال). بدل ما تحاول تمنع التكرار تمامًا (صعب)، بتصمّم العملية إنها آمنة للتكرار — تنفيذها مرة أو عشرة نفس النتيجة.
تحويل البيانات المعقّدة لجداول مسطّحة سريعة القراءة.
الـ Indexing بيحوّل البيانات المعقّدة والمبعثرة (أسعار، مخزون، خصائص EAV) لـ جداول مسطّحة محسّنة جاهزة للقراءة السريعة.
بياخد البيانات المصدرية، يعمل الحسابات المطلوبة مرة واحدة، ويخزّن النتيجة في جدول index. الـ storefront بيقرا من الجدول الجاهز مباشرة بدل ما يحسب كل مرة.
Magento (خصوصًا EAV) مرن بس بطيء في القراءة. القراءة بتحصل ملايين المرات (كل زائر)، الكتابة نادرة (تعديل منتج). فمنطقي نتعب مرة في الكتابة (نحضّر الـ index) عشان نرتاح كل مرة في القراءة.
- Update on Save — reindex فوري كل حفظ (يبطّئ الحفظ).
- Update on Schedule — الـ cron بيعمل reindex جزئي للمتغيّر (الموصى به).
فريق الكتالوج بيشتكي إن حفظ أي منتج بياخد وقت طويل، والـ import بقى بطيء جدًا. إيه السبب المحتمل؟
على الأرجح الـ indexers على "Update on Save". كل حفظ بيشغّل reindex فوري، فمع كل منتج بتستنى العملية. الحل: أحوّلهم لـ "Update on Schedule" فالحفظ يبقى سريع، والـ cron بيعمل reindex في الخلفية.
عشان الـ Schedule بيفصل الحفظ عن الـ reindex. بيسجّل المتغيّر بس، والـ reindex بيحصل لاحقًا وبشكل جزئي (للمتغيّر فقط) — أخف بمراحل.
غيّرت سعر منتج، بس السعر القديم لسه ظاهر في الموقع. ليه، وإزاي تحلّها؟
الـ storefront بيقرا من جدول الـ index اللي لسه فيه السعر القديم. لازم reindex عشان الجدول يتحدّث. لو على schedule، أتأكد إن الـ cron شغّال. لو مستعجل، أعمل reindex يدوي للـ price indexer. وكمان أشيك الـ cache (ممكن يكون مخزّن الصفحة القديمة).
لأن الـ storefront مبيقراش السعر من مصدره المعقّد — بيقرا من الـ index الجاهز (للسرعة). فلو الـ index ماتحدّثش، السعر القديم بيفضل. ده جوهر فكرة الـ indexing.
السؤال اللي بيقيس إزاي بتفكّر معماريًا وبتربط التقنيات.
متجر كبير هيعمل عرض ضخم (Black Friday). متوقّع ضغط عالي جدًا. إزاي تجهّز البنية عشان تستحمّل، مستخدمًا Redis و RabbitMQ و Indexing؟
- Varnish + Redis — full page cache على Varnish للصفحات، وRedis للـ cache الداخلي والـ sessions (عشان الـ scaling).
- Indexing على Schedule — عشان تحديثات المنتجات والأسعار متبطّأش الموقع وقت الضغط، والـ cron يعمل reindex جزئي.
- RabbitMQ — أي عملية تقيلة (إيميلات، تحديث ERP، معالجة) تروح للـ queue وتتنفّذ في الخلفية، فمسار الشراء يفضل سريع.
- Horizontal scaling — كذا web server (stateless بفضل sessions في Redis) ورا load balancer.
كل تقنية بتحل جزء: Redis/Varnish يخفّفوا القراءة، Indexing يخلّي القراءة سريعة أصلًا، RabbitMQ يبعّد العمليات التقيلة عن مسار المستخدم. الثلاثة مع بعض = نظام يستحمّل الضغط.
جاهز للتقنيات الثلاثة ✓
دلوقتي فاهم Redis و RabbitMQ و Indexing — إزاي كل واحدة شغّالة، ليه، وإزاي تطبّقها في سيناريوهات حقيقية. والأهم، إزاي تركّبهم مع بعض.
الخلاصة: Redis يسرّع القراءة المتكرّرة، RabbitMQ يبعّد العمليات التقيلة، Indexing يخلّي القراءة سريعة أصلًا. في الإنترفيو، اربطهم ببعض — ده بيبيّن التفكير المعماري اللي المدير بيقدّره. بالتوفيق! 🎯
خلّصت الدرس؟علّمه عشان تتابع تقدّمك في الكورس.
أسئلة شائعة
Magento 2 بيستخدم Redis في إيه؟
Redis مخزن بيانات in-memory سريع جدًا، وMagento بيستخدمه كـ default cache للـ config والـ blocks والـ layouts، وكمان لتخزين الـ sessions. بدل ما Magento يعيد الحسابات التقيلة أو يضرب الـ DB كل مرة، بيقرا النتيجة من Redis. ولأنه في الرام بيتستخدم للـ cache والـ sessions، مش للبيانات الدائمة زي الطلبات.
ليه المستخدمين بيتسجّلوا خروج أو السلة بتضيع لما يبقى عندي أكتر من web server؟
لأن الـ sessions متخزّنة محليًا على كل سيرفر، فلما الـ load balancer يوجّه المستخدم لسيرفر تاني ميلاقيش الـ session بتاعه. الحل إنك تخزّن الـ sessions في Redis مشترك تقرا منه كل السيرفرات، وده اللي بيخلّي الـ services stateless وجاهزة للـ horizontal scaling.
إمتى أستخدم RabbitMQ في Magento 2؟
لما يكون عندك عملية بطيئة أو تقيلة مش لازم تحصل فورًا، زي إرسال إيميل أو إرسال الـ order لـ ERP خارجي أو معالجة import كبير. الـ publisher بيحط رسالة في الـ queue ويكمّل، والـ consumer بينفّذها في الخلفية، فالـ checkout مايستناش العملية البطيئة.
ليه رسالة الـ queue بتتنفّذ مرتين وإزاي أمنع ده؟
ده بيحصل لو الـ consumer نفّذ الرسالة ووقع قبل ما يأكّد استلامها (ack)، فالـ queue بيعيد إرسالها. الحل هو idempotency: تصمّم الـ consumer بمفتاح فريد لكل عملية بيشيك عليه، فلو نفس الرسالة وصلت تاني ميكرّرش التنفيذ.
ما الفرق بين Update on Save و Update by Schedule في Magento 2؟
الـ Update on Save بيعمل reindex فوري مع كل حفظ، وده بيبطّئ حفظ المنتجات والـ import. الـ Update by Schedule بيسجّل المتغيّر في changelog عن طريق MView والـ DB triggers، والـ cron بيعمل reindex جزئي للمتغيّر بس، وده الموصى به في الـ production بشرط إن الـ cron شغّال.
ليه غيّرت سعر منتج في Magento 2 والسعر القديم لسه ظاهر؟
لأن الـ storefront بيقرا السعر من جدول الـ index الجاهز، فلو الـ index ماتحدّثش بيفضل السعر القديم ظاهر. لو الـ indexers على schedule اتأكد إن الـ cron شغّال، ولو مستعجل اعمل reindex يدوي للـ price indexer، ومتنساش تشيك الـ cache لأنه ممكن يكون مخزّن الصفحة القديمة.
إزاي أجهّز متجر Magento 2 لـ flash sale زي Black Friday؟
استخدم Varnish للـ full page cache وRedis للـ cache الداخلي والـ sessions، وخلّي الـ indexers على Schedule عشان تحديثات الأسعار متبطّأش الموقع. ابعت العمليات التقيلة زي الإيميلات وتحديث الـ ERP لـ RabbitMQ، ووسّع horizontally بكذا web server stateless ورا load balancer.