Redis / المتوسط: صحة التطبيق والتنسيق / الدرس 9
دلالات MULTI وEXEC وWATCH والأخطاء
استخدم عزل المعاملة والفحص التفاؤلي دون افتراض تراجع SQL، وافحص خطأ الصف والتنفيذ ونتيجة الحفظ المجهولة منفصلة.
في هذه الصفحة
أهداف الدرس
- شرح الأوامر المصطفة وفحص كل رد EXEC.
- تصميم إعادة WATCH محدودة وحالة اتصال نظيفة.
تسلسل معاملة Redis مجموعة أوامر مصفوفة
تبدأ MULTI الصف وتنفذ EXEC المجموعة دون إدخال طلب عميل آخر في وسطها. لا تعني QUEUED نجاح التنفيذ. تلغي DISCARD غير المنفذ لا ما بعد EXEC. لا تقدم Redis تراجع SQL عاماً؛ قد يجتمع خطأ التنفيذ والنجاح وتمنع أخطاء صف معينة الكل. افحص المصفوفة والثابت، وميز العزل والمتانة وذرية الأنظمة والتحقق.
اقرأ كل الردود عند خطأ نوع
افترض غياب المفتاحين. تنشئ SET سلسلة1، ثم تنجح زيادتها ويفشل HSET بنوعها وتنجح زيادة الثاني. لا تلغي EXEC الزيادات بسبب الخطأ؛ النهائي2 و1. المثال الخاطئ عمداً لا ينفذ ويشرح لماذا لا تعلن تراجعاً كلياً آلياً.
SET lab:tx:a 1
MULTI
INCR lab:tx:a
HSET lab:tx:a field value
INCR lab:tx:b
EXEC
GET lab:tx:a
GET lab:tx:bEXEC logical replies: [2, WRONGTYPE, 1]
Final values: a=2, b=1تتضمن الردود2 وخطأ WRONGTYPE و1 وتبقى التغييرات؛ قيمتا GET النهائيتان2 و1 بالعينة.
تحمي WATCH محاولة تعتمد على قراءة بشرط
تراقب WATCH مفاتيح قبل EXEC وقد تجهض عند تغيرها فيعاد القرار والقراءة. يعد الحديث الانتهاء والإخلاء تعديلاً، واختلف الانتهاء قبل6.0.9. الحالة للاتصال فتحتاج مساراً مخصصاً لا مشاركة عشوائية. أعد القراءة والحساب بحد، وميز EXEC المجهضة عن مصفوفة نجاح بخطأ تنفيذ.
نمذج فحص إصدار تفاؤلي
يرفض النموذج إصداراً قديماً ويقبل المطابق، ولا ينفذ WATCH لغياب المفتاح والاتصال والتتبع. يوضح قرار الإعادة: لا يحول الرفض إلى كتابة قديمة بلا شرط. إذا وجد أثر خارجي فاحفظ هويته؛ لا تثبت الكتابة المشروطة تسليم الخارج مرة.
def may_commit(expected_version, current_version):
return expected_version == current_version
assert not may_commit(2, 3)
assert may_commit(3, 3)يرفض القديم ويقبل الجديد بالنموذج فقط دون معاملة أو قفل Redis.
نظف الحالة وصالح EXEC المجهولة
لا ترجع اتصال MULTI أو WATCH للمجمع بعد استثناء دون تنظيف. اتبع مساعدات المكتبة. قد تجهل نتيجة EXEC بعد إرسالها وفقد الرد، فتكرر الإعادة الأثر. تلزم مفاتيح الشق نفسه في Cluster وقد تقيد الخدمات التدفق. افصل أخطاء الصف والتنفيذ والإجهاض والفقد واختبر الثابت لا وجود MULTI فقط.
الأخطاء الشائعة وإصلاحها
تفترض إعادة النجاح بعد WRONGTYPE
- لماذا يحدث؟
- فسرت الأخطاء كتراجع SQL.
- كيف تصلحه؟
- افحص المصفوفة وصالح الناجح صراحة.
- كيف تتجنب تكراره؟
- اختبر الخطأ بعد كتابة سابقة.
تكتب محاولة WATCH المجهضة فوق الجديد
- لماذا يحدث؟
- أعادت المحاولة قراءة قديمة.
- كيف تصلحه؟
- أعد القراءة والحساب ضمن حد.
- كيف تتجنب تكراره؟
- افصل الرفض عن النجاح.
يحتفظ اتصال المجمع بحالة معاملة
- لماذا يحدث؟
- أهمل التنظيف الصف أو المراقبة.
- كيف تصلحه؟
- استخدم دورة المكتبة الموثقة.
- كيف تتجنب تكراره؟
- اختبر إعادة الاستخدام بعد كل خطأ.
اختبر فهمك
1. تعيد EXEC نجاحين وخطأ نوع. هل يصح قول لم يحدث شيء؟
اعرض الحل المشروح
لا. ربما طبقت الأوامر الناجحة وبقيت آثارها. فسر كل رد وشرط العمل اللاحق، واحفظ هوية الحدث قبل التعافي أو الإعادة. تنفيذ معاملة Redis معزول عن طلبات العملاء الآخرين، لكن هذه الخاصية لا تعني تراجعاً عاماً عندما يفشل أحد أوامرها أثناء التنفيذ.
2. تجهض WATCH لتغيير كاتب آخر. ماذا تفعل الإعادة الصحيحة؟
اعرض الحل المشروح
يجب قراءة القيم الحالية مجدداً وإعادة حساب القرار، ثم محاولة التدفق المدعوم ضمن ميزانية محاولات محدودة. تهزم إعادة القيمة القديمة وإزالة الفحص التزامن التفاؤلي المقصود. تأكد أيضاً من أن طلبات أخرى لا تشارك الاتصال بينما تنتمي حالته إلى هذه المحاولة.
أهم ما تعلمته
- لا يعني عزل Redis تراجع SQL.
- صنف EXEC ونظف الاتصال قبل الاستخدام.