Redis / الأساسي: المفاتيح والبنى المحدودة / الدرس 4
القوائم وطوابير العمل والتسليم
استخدم قائمة مرتبة للعمل المحدود وميز الإزالة عن الإقرار، وصمم الإعادة والتعافي حول الفشل لا معالجة مرة واحدة مفترضة.
في هذه الصفحة
أهداف الدرس
- شرح طرفي القائمة وسلوك العميل المنتظر.
- تحديد نوافذ الفقد والتكرار في الطابور.
اختر الطرفين لتحديد ترتيب الطابور
تحفظ القائمة عناصر مرتبة وتعمل على طرفيها. يمكن لـ LPUSH مع RPOP تحقيق FIFO ويغير عكس الأطراف الاتفاق. قد تتكرر الحمولة فالقائمة ليست مجموعة، فافصل الهوية. ينتظر السحب الحاجب دون دوران ويحتجز اتصالاً يحتاج مهلة وإيقافاً. تبقى السعة والطول والاحتفاظ مسؤولية التطبيق رغم ذرية العملية.
استدل على اتفاق FIFO معلن
افترض الفراغ. تضع LPUSH job-a ثم job-b بالأمام، فتزيل RPOP job-a من الخلف أولاً ثم job-b. لا عملية Redis أو مستهلك حاجب هنا. يعني السحب الإزالة لا اكتمال الأثر أو التدقيق الدائم؛ وضح ذلك قبل عمل لا يقبل الفقد.
LPUSH lab:jobs job-a
LPUSH lab:jobs job-b
RPOP lab:jobs
RPOP lab:jobsjob-a
job-bترتيب السحب job-a ثم job-b، وعدد القائمة في الرد ليس إقرار عامل.
الإزالة والاكتمال حدثان مختلفان
إذا انهار العامل بعد السحب غابت المهمة من القائمة البسيطة. قد يحفظ نقل ذري لقائمة معالجة ملكية قابلة للتعافي ويحتاج إقراراً وتقادم عمل ومعالجة بلا تكرار. تساعد LMOVE وBLMOVE منذ6.2 ولا تنفذان البروتوكول كله، وتلزم قيود الشق في Cluster. قد يسبق الأثر الخارجي الإقرار فتتكرر المهمة عند التعافي.
نمذج الاكتمال الآمن للتكرار صراحة
يسجل النموذج هويات مكتملة ويمنع تطبيقاً ثانياً، فيميز التسليم والأثر. المجموعة ذاكرة محلية؛ يحتاج الحقيقي تنسيقاً دائماً مع الأثر أو خدمة آمنة للإعادة. قد يكسر الانهيار بين الخطوتين التنفيذ الساذج. النموذج ثابت مطلوب لا حل إنتاج لمرة واحدة.
completed = set()
effects = []
def apply_once(job_id):
if job_id in completed:
return 'duplicate'
effects.append(job_id)
completed.add(job_id)
return 'applied'
assert apply_once('lab-job-1') == 'applied'
assert apply_once('lab-job-1') == 'duplicate'
assert effects == ['lab-job-1']يسجل أثراً محلياً واحداً لاستدعاءين دون متانة انهيار أو أثر خارجي أو معاملة Redis.
حد التراكم واختر اللبنة المناسبة
قد يتجاوز المنتج العامل فيستهلك الذاكرة. حدد القبول والتأخير والفشل والتنبيه من السعة والفقد. يرمي التقليم عناصر فلا يعالج تراكم عمل دائم عشوائياً. تقدم التدفقات إقراراً وتاريخاً مختلفين وتحتاج هوية واحتفاظاً أيضاً. اختر مخبأ للعمل أم طابوراً مرجعياً ثم صمم الاستمرار والتعافي والرصد.
الأخطاء الشائعة وإصلاحها
تختفي مهمة مسحوبة بعد فشل العامل
- لماذا يحدث؟
- اعتُبرت الإزالة اكتمالاً دائماً.
- كيف تصلحه؟
- استخدم معالجة وإقراراً وتعافياً مراجعة.
- كيف تتجنب تكراره؟
- اختبر الانهيار قبل الأثر وبعده والإقرار.
تعمل المهام بعكس الترتيب
- لماذا يحدث؟
- لا يحقق الطرفان الاتفاق المطلوب.
- كيف تصلحه؟
- حدد الطرفين واختبرهما.
- كيف تتجنب تكراره؟
- استخدم مهمتين لإثبات الترتيب.
ينمو التراكم لضغط الذاكرة
- لماذا يحدث؟
- لا يحد معدل الإنتاج والإعادة بسعة المعالجة.
- كيف تصلحه؟
- أضف قبولاً وضغطاً عكسياً ومعالجة فشل مراجعة.
- كيف تتجنب تكراره؟
- راقب أقدم عمل والطول بسياسة احتفاظ.
اختبر فهمك
1. يرسل العامل إخطاراً وينهار قبل الإقرار. ما افتراض التصميم الآمن؟
اعرض الحل المشروح
افترض أن المهمة قد تسلم مرة أخرى رغم إرسال الإخطار فعلاً. احتفظ بهوية حدث مستقرة، واستخدم تسليماً آمناً للإعادة أو بروتوكول تنسيق دائم يناسب الأثر. لا تنسق قائمة المعالجة وحدها Redis وخدمة الإخطار الخارجية ذرياً. اختبر تحديداً نافذة الانهيار بعد الأثر وقبل حفظ الإقرار.
2. هل تناسب LTRIM استجابة آلية لكل تراكم؟
اعرض الحل المشروح
لا. يحذف التقليم عناصر عمداً وقد يدمر عملاً يجب الاحتفاظ به. ربما تسمح به ذاكرة تاريخ مؤقت محدود، لكن الطابور المرجعي يحتاج قرارات صريحة للاحتفاظ والتعافي والحمل الزائد. حدد أقدم مهمة معلقة ومعدل الفشل وسعة المنتجين والمستهلكين قبل اختيار العلاج، ولا تستنتجه من طول القائمة وحده.
أهم ما تعلمته
- ذرية الطابور ليست ضمان تسليم كاملاً.
- يحتاج الترتيب والإقرار والهوية والتراكم تصميماً صريحاً.