الحالة
تشغّل كروجر آلاف متاجر البقالة عبر الولايات المتحدة. منصة التوصيل لديهم تفعل شيئاً صعباً حقاً: تعرض لكل عميل ما هو متاح في متجره المحلي المحدد، محدّثاً في شبه وقت فعلي مع تغيّر مخزون الرفوف. التحدي أن بيانات المخزون شبه الفورية، مع ملايين المستخدمين يتصفحون في آنٍ واحد، تخلق مشكلة تحميل قواعد بيانات لا تواجهها معظم منصات التجزئة. عند انضمامنا للمشروع، كان زمن استجابة صفحات الكتالوج غير مقبول تحت التحميل المتزامن المستمر. السبب الجذري كان مزيجاً من عوامل: روابط غير مفهرسة عبر جداول المنتجات والمتاجر والمخزون؛ وعمليات الكتابة لتحديث المخزون كانت تكتسب أقفال جداول واسعة بدلاً من أقفال مستوى الصف. عالجنا الثلاثة. خفّض نهج الفهارس المركّبة على أكثر أنماط الاستعلام شيوعاً وقت تنفيذ الاستعلام بشكل كبير. أُعيدت كتابة خط تحديث المخزون لاستخدام القفل على مستوى الصف. توضع نسخ Redis المؤقتة أمام جميع صفحات تصفح الكتالوج.
ما كان يجب أن يتغير
كانت صفحات الكتالوج بطيئة تحت التحميل المتزامن المستمر — أظهرت البيانات روابط غير مفهرسة عبر ثلاثة جداول كبيرة تصل إلى مسح كامل تحت التحميل. كانت عمليات مزامنة المخزون الجماعية من المتاجر تكتسب أقفال مستوى الجدول، مما يخلق ارتفاعات في التأخير في القراءة لجميع المستخدمين خلال نوافذ المزامنة.
لقد تغيرت
حل ثلاثي الأجزاء: فهارس مركّبة على جميع أنماط استعلام المنتج×المتجر×الفئة؛ خط المخزون أُعيدت كتابته بقفل مستوى الصف للقضاء على ارتفاعات تأخير نافذة المزامنة؛ تخزين Redis مؤقت على جميع مسارات تصفح الكتالوج مع TTL مطابق لإيقاع مزامنة المخزون.
ما حصل عليه العميل
- 01 فهرسة مركّبة على جميع مسارات استعلام الكتالوج الساخنة
- 02 قفل مستوى الصف — كتابات المزامنة لا تحجب القراءات
- 03 TTL ذاكرة Redis المؤقتة مطابق لإيقاع مزامنة المخزون
- 04 يتوسع إلى 2700+ متجر مع مخزون فوري لكل منها
