تحل Cloudflare Queues المشكلة التي يصطدم بها كل تطبيق بدون خادم عاجلاً أم آجلاً: يصل طلب يستدعي عملاً لا ينبغي أن ينتظره المستخدم. إرسال بريد التأكيد، تغيير حجم الملف المرفوع، مزامنة السجل مع طرف ثالث. على خادم تقليدي تسلّم ذلك إلى عملية خلفية. على Workers لا توجد عملية تسلّمها إليها أصلاً.
الحلول الالتفافية المعتادة أسوأ مما تبدو. تنفيذ العمل داخل الطلب نفسه يجعل المستخدم ينتظر مزوّد البريد. وإطلاق طلب نحو Worker آخر دون انتظاره يفقد المهمة كلما انتهى الاستدعاء الأصلي أولاً. ولا واحد من الأسلوبين ينجو من انقطاع لدى المزوّد.
ما الذي يمنحك إياه الطابور: المتانة وإعادة المحاولة، لا السرعة. المنتِج يكتب رسالة ويعود فوراً، ويلتقطها Worker مستهلك منفصل، وإذا فشل المستهلك تعود الرسالة إلى الطابور بدل أن تضيع في العدم. هذه هي القيمة كلها. وإذا كانت مهمتك الخلفية لا تحتمل إعادة التنفيذ، فلن ينقذك الطابور.
كيف تتركب القطع معاً
للطابور طرفان، وكلاهما Workers.
المنتِج هو أي Worker مرتبط بالطابور. يستدعي send مع جسم الرسالة، ويعود ذلك الاستدعاء فور تخزين الرسالة تخزيناً دائماً. ينتهي طلب المستخدم دون أن ينتظر العمل نفسه.
المستهلك هو Worker يحتوي على معالج طابور. تستدعيه Cloudflare بدفعة من الرسائل، ويقرّ المعالج بكل رسالة يعالجها بنجاح. وكل ما لا يُقَرّ به يُعاد تسليمه.
سلوك إعادة التسليم هو الجزء الذي يستحق أن تصمم حوله. قد تصل الرسالة أكثر من مرة، ما يعني أن المستهلك يجب أن يكون قابلاً للتكرار دون أثر جانبي. خصم مبلغ من بطاقة داخل مستهلك طابور دون مفتاح تكرار هو الطريق المضمون إلى رد الأموال للعملاء. إرسال بريد مرتين مزعج، أما تحصيل الدفع مرتين فحادثة دعم.
يلتقط طابور الرسائل الميتة الرسائل التي تفشل مراراً. بدونه تُعاد محاولة الرسالة المعطوبة نهائياً حتى تستنفد محاولاتها ثم تختفي. ومعه تهبط في مكان تستطيع فحصها فيه. اضبطه قبل أن تحتاج إليه.
كم تكلّف العملية الواحدة فعلاً
نموذج التسعير غريب بما يكفي ليوقع الفرق في الخطأ، لأن الفوترة ليست لكل رسالة.
تُحتسب عملية واحدة لكل 64 KB من البيانات تُكتب أو تُقرأ أو تُحذف. الرسالة الأقل من 64 KB التي تُسلَّم بشكل طبيعي تكلّف ثلاث عمليات: كتابة وقراءة وحذف. أما رسالة بحجم 127 KB فتكلّف عمليتين لكل إجراء، أي ست عمليات إجمالاً للتسليم الواحد نفسه.
| Workers Free | Workers Paid | |
|---|---|---|
| المتضمَّن | 10,000 عملية يومياً | 1,000,000 عملية شهرياً |
| ما بعد ذلك | غير متاح | 0.40 دولار لكل مليون عملية |
| حركة الخروج | لا شيء | لا شيء |
تغيّر إعادات المحاولة الحساب كله. كل إعادة تسليم قراءة إضافية، والكتابة إلى طابور الرسائل الميتة كتابة إضافية. المستهلك الذي يفشل خمس مرات على رسالة قبل أن ينجح يكلّف أكثر بكثير من ثلاث عمليات، وهذا سبب وجيه لإصلاح مستهلك غير مستقر بدل رفع عدد محاولاته.
احسب الأرقام على حركتك أنت قبل أن تفترض أنها رخيصة. مليون رسالة شهرياً بثلاث عمليات لكل رسالة تعني ثلاثة ملايين عملية، وهي فوق حصة الخطة المدفوعة وتكلّف نحو ثمانين بنساً. هذا رخيص فعلاً. أما عشرة ملايين رسالة يومياً فحديث آخر تماماً.
الحدود التي تقرر مدى الملاءمة
من توثيق حدود Queues لدى Cloudflare، جرى التحقق منه في أغسطس 2026.
| الحد | القيمة |
|---|---|
| الطوابير لكل حساب | 10,000 |
| الحجم الأقصى للرسالة | 128 KB |
| الرسائل في الإرسال الدفعي | 100، أو 256 KB إجمالاً |
| محاولات إعادة الرسالة | 100 |
| مدة الاحتفاظ | قابلة للضبط حتى 14 يوماً |
| التراكم لكل طابور | 25 GB |
| استدعاءات المستهلك المتزامنة | 250، بنمط الدفع فقط |
| زمن تشغيل المستهلك | 15 دقيقة |
| الإنتاجية لكل طابور | 5,000 رسالة في الثانية |
اثنان من هذه الحدود أثقل وزناً من البقية. سقف 128 KB لكل رسالة يعني أنك لا تضع الملفات في الطابور. تضع مؤشراً في الطابور والملف في R2، وهي الصيغة الصحيحة أصلاً. التراكم البالغ 25 GB هو ما يحميك من الكارثة الصامتة: إذا تعطل مستهلكك يوم الجمعة ولم ينتبه أحد، يمتلئ الطابور ثم يرفض الرسائل الجديدة بخطأ تخزين بدل أن يتخلص منها بصمت.
إنتاجية 5,000 رسالة في الثانية سخية، لكنها محسوبة لكل طابور على حدة. الطابور الواحد المزدحم عنق زجاجة يمكنك تفاديه بالتصميم عبر توزيع الحمل على عدة طوابير.
متى تكون Cloudflare Queues إجابة خاطئة
عندما يكون العمل متزامناً حقاً. إذا كان المستخدم يحتاج النتيجة على الشاشة، فوضعها في طابور يضيف رحلة إضافية ومشكلة استقصاء. نفّذها داخل الطلب واجعلها سريعة.
عندما تحتاج معالجة مرتبة ولمرة واحدة بالضبط. توفر Queues تسليماً لمرة واحدة على الأقل. وكل ما يتطلب ترتيباً صارماً أو دلالة تنفيذ لمرة واحدة بالضبط يحتاج تنسيقاً لا يقدمه الطابور، وعلى Cloudflare يعني ذلك عادةً استخدام Durable Object.
عندما تكون المهمة مجدولة لا مُطلَقة بحدث. التنظيف الليلي لا يحتاج طابوراً. مشغّل cron يستدعي Worker مباشرة أبسط وأقل أجزاءً متحركة.
عندما يتجاوز العمل 15 دقيقة. المستهلك الذي يتخطى حد زمن التشغيل سيتوقف قسراً في منتصف المهمة. العمليات الطويلة متعددة الخطوات تريد Cloudflare Workflows، المبني للتنفيذ الدائم عبر الخطوات، لا مستهلك طابور يحاول الاحتفاظ بالحالة ربع ساعة.
يغطي دليلنا حول بناء واجهة API بدون خادم باستخدام Cloudflare Workers مسار الطلب الذي ينتج هذه المهام عادةً، ويشرح Cloudflare Workers مقابل AWS Lambda كيف يختلف نموذج التنفيذ عن نمط SQS مع Lambda الذي تصل به معظم الفرق.
من أين تبدأ
اختر القطعة الوحيدة من العمل في معالج الطلبات التي لا يحتاج المستخدم إلى انتظارها، وانقل تلك فقط. امنحها طابور رسائل ميتة من اليوم الأول، واجعل المستهلك قابلاً للتكرار دون أثر جانبي، وراقب مؤشر التراكم بدل افتراض أنه فارغ.
تصمم Mecanik معماريات الحافة وتراجعها عبر فريق تطوير البرمجيات لدينا، بما في ذلك الجزء الذي يسأل فيه أحدهم إن كانت المهمة تحتاج طابوراً من الأساس. معظم الأنظمة تحتاج واحداً أو اثنين، لا واحداً لكل ميزة.
تدوينات ذات صلة: Cloudflare Hyperdrive: Postgres من الحافة ، كيفية بناء تطبيق ويب في 2026 - دليل المطور البريطاني ، Cloudflare D1: بناء قاعدة بيانات SQL بدون خادم على الحافة وCloudflare Workers AI: تشغيل نماذج الذكاء الاصطناعي على الحافة في 2026 .
الأسئلة الشائعة
كم تكلفة Cloudflare Queues؟ تتضمن خطة Workers Free مقدار 10,000 عملية يومياً، وتتضمن الخطة المدفوعة مليون عملية شهرياً، مع عمليات إضافية بسعر 0.40 دولار لكل مليون ودون أي رسوم خروج. وتُحتسب عملية واحدة لكل 64 KB تُكتب أو تُقرأ أو تُحذف، لذا تكلّف الرسالة العادية الأقل من 64 KB ثلاث عمليات إجمالاً: كتابة وقراءة وحذف.
ما الذي يُحتسب عملية في Cloudflare Queues؟ كل 64 KB من البيانات تُكتب أو تُقرأ أو تُحذف. الرسالة الأصغر من 64 KB تكلّف عملية واحدة لكل إجراء، بينما تكلّف رسالة بحجم 127 KB عمليتين لكل إجراء. وتضيف كل إعادة محاولة قراءة أخرى، وتضيف الكتابة إلى طابور الرسائل الميتة كتابة أخرى، لذا يكلّف المستهلك غير المستقر أكثر بكثير من العمليات الثلاث الأساسية لكل رسالة.
ما الحجم الأقصى للرسالة في Cloudflare Queues؟ الحد هو 128 KB لكل رسالة، مع تقييد الإرسال الدفعي بـ 100 رسالة أو 256 KB إجمالاً. وبسبب هذا السقف تخزّن الحمولة في R2 أو في مخزن كائنات آخر وتضع مؤشراً فقط في الطابور، وهو التصميم الأفضل بصرف النظر عن الحد.
هل تضمن Cloudflare Queues التسليم لمرة واحدة بالضبط؟ لا. التسليم لمرة واحدة على الأقل، لذا قد تصل الرسالة أكثر من مرة ويجب أن يكون المستهلك قابلاً للتكرار دون أثر جانبي. تحصيل دفعة أو إصدار رصيد داخل مستهلك دون مفتاح تكرار سيتضاعف يوماً ما. أما الترتيب الصارم أو دلالة المرة الواحدة بالضبط فيحتاجان إلى Durable Object بدلاً من ذلك.
متى لا ينبغي أن أستخدم Cloudflare Queues؟ عندما ينتظر المستخدم النتيجة، وعندما تحتاج ترتيباً صارماً أو معالجة لمرة واحدة بالضبط، وعندما تكون المهمة مجدولة لا مُطلَقة بحدث ويكفيها مشغّل cron، أو عندما يستمر العمل أطول من حد 15 دقيقة المفروض على المستهلك. الحالة الأخيرة هي بالضبط ما وُجدت Cloudflare Workflows من أجله.
التعليقات