Redis ولا Valkey؟ إعداد الكاش والـ Sessions في Magento 2

لو متجرك على آخر patch من Magento 2.4.6 أو 2.4.7 أو 2.4.8، متطلبات Adobe بقت بتذكر Valkey 8.1 للكاش والـ sessions، و Redis بقى مكتوب قدّامه إنه غير مدعوم. وفي Magento 2.4.9 المطلوب Valkey 9، والأوامر نفسها اتغيّرت.

Valkey مشروع مفتوح المصدر متفرّع من Redis وبيتكلّم نفس البروتوكول، عشان كده التحويل في معظمه تغيير إعدادات مش تغيير كود. لو محتاج تفهم Magento بيستخدم الكاش والـ sessions في إيه أصلًا، ابدأ بـ درس Redis و RabbitMQ و Indexing.

أنهي إصدار Magento محتاج Valkey؟

إزاي تظبط الكاش والـ sessions في 2.4.8 وأقدم؟

الخيارات لسه اسمها redis، بس بتشاور على سيرفر Valkey:

bin/magento setup:config:set --cache-backend=redis --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0
bin/magento setup:config:set --page-cache=redis --page-cache-redis-server=127.0.0.1 --page-cache-redis-db=1
bin/magento setup:config:set --session-save=redis --session-save-redis-host=127.0.0.1 --session-save-redis-log-level=4 --session-save-redis-db=2

كل نوع ليه رقم database مختلف: 0 للكاش العادي، و 1 للـ page cache، و 2 للـ sessions. الأوامر دي بتكتب الإعدادات في app/etc/env.php. ولو بتستخدم Varnish للصفحات، سطر الـ page cache مش ضروري، وتفاصيل Varnish في مقال إعداد Varnish كـ Full Page Cache.

إزاي تظبطهم في Magento 2.4.9؟

bin/magento setup:config:set --cache-backend=valkey --cache-backend-valkey-server=127.0.0.1 --cache-backend-valkey-db=0
bin/magento setup:config:set --page-cache=valkey --page-cache-valkey-server=127.0.0.1 --page-cache-valkey-db=1
bin/magento setup:config:set --session-save=valkey --session-save-valkey-host=127.0.0.1 --session-save-valkey-db=2

Magento 2.4.9 نقل طبقة الكاش لـ Symfony Cache، وده غيّر شكل الإعدادات في env.php. عشان كده ماتنسخش snippet قديم من مقال أو مشروع تاني: شغّل الأوامر وافتح الملف اللي اتولّد. وحسب Adobe، استخدام igbinary مع Symfony Cache بيصغّر حجم عناصر الكاش حوالي 45% وبيخلّيها أسرع بنسبة 5 لـ 10%.

إيه الإعدادات اللي بتفرق في الأداء؟

• افصل الكاش عن الـ sessions: أرقام databases مختلفة كحد أدنى، والأفضل instance منفصل لكل واحد.
• الـ persistence للـ sessions بس: فعّل RDB أو AOF على instance الـ sessions. الكاش ممكن يتبني من جديد، فمش محتاج persistence.
• الذاكرة: instance الكاش حجمه على الأقل قد مجلد var/cache.
• Lua: سيب use_lua=0 و use_lua_on_gc=1. تفعيل use_lua على 2.4.7 و 2.4.8 ممكن يبوّظ الكاش.
• sessions كتير في نفس الوقت: على clusters كبيرة، خلّي max_concurrency على الأقل 10% من عدد PHP processes.
• أكتر من سيرفر web: استخدم الـ L2 cache (RemoteSynchronizedCache)، وحمّل مفاتيح زي GLOBAL_PLUGIN_LIST و SYSTEM_DEFAULT مسبقًا بـ preload_keys مع الـ id_prefix بتاع متجرك.

وده إعدادات سيرفر Valkey اللي Adobe بتوصي بيها:

lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
lazyfree-lazy-user-del yes
replica-lazy-flush yes

مكان الكاش ده في معمارية متجر كبير، جنب قاعدة البيانات والـ queues، متشرح في درس System Design لمتجر e-commerce، وأنواع الكاش جوّه Magento نفسه في درس قاعدة البيانات والأداء.

إزاي تنقل متجر شغّال من Redis لـ Valkey؟

1. جهّز Valkey بالإصدار المطلوب لإصدار Magento بتاعك، وجرّب التحويل على الـ staging الأول.
2. اختار وقت زيارات قليلة: الـ sessions الموجودة مش هتتنقل، فالعملاء المسجّلين هيحتاجوا يسجّلوا دخول تاني.
3. شغّل أوامر setup:config:set المناسبة لإصدارك.
4. امسح الكاش بـ bin/magento cache:flush.
5. اتأكد من الاتصال بـ valkey-cli ping، وبص على الطلبات بـ valkey-cli monitor لثواني بس، لأنه تقيل على السيرفر.
6. تابع زمن تحميل الصفحات وسجلات الأخطاء في أول كام ساعة.

Checklist التحويل لـ Valkey

• إصدار Valkey مطابق لمتطلبات إصدار Magento بتاعك
• الكاش والـ page cache والـ sessions على databases أو instances منفصلة
• الـ persistence مفعّل على instance الـ sessions بس
• use_lua=0 و use_lua_on_gc=1
• env.php اتراجع بعد الأوامر، مش منسوخ من مصدر قديم
• التحويل اتعمل في وقت زيارات قليلة بعد تجربة على الـ staging
• cache:flush اتنفّذ، و valkey-cli ping بيرجّع PONG