العودة إلى المدونة

شرح وضع queue mode في n8n: Redis والـ workers ومتى تحتاجه

فريق تحرير IM Host14 أكتوبر 20267 دقائق قراءة
شرح وضع queue mode في n8n: Redis والـ workers ومتى تحتاجه

وضع queue mode في n8n هو إعداد التوسّع الذي تكتفي فيه النسخة الرئيسية من n8n باستقبال المشغّلات (triggers) والـ webhooks، وتضع كل تنفيذ كمهمة في طابور داخل Redis، بينما تلتقط عمليات منفصلة تسمى workers هذه المهام وتنفذها وتكتب النتائج في PostgreSQL. تفعّله بضبط EXECUTIONS_MODE=queue على النسخة الرئيسية وعلى كل worker، وربطها جميعًا بنفس Redis ونفس قاعدة البيانات، واستخدام مفتاح N8N_ENCRYPTION_KEY واحد للجميع، ثم تشغيل الـ workers بالأمر n8n worker.

الوضع العادي مقابل queue mode

في الوضع العادي تقوم عملية n8n واحدة بكل شيء: تقدم المحرر والـ API، وتستقبل الـ webhooks، وتطلق الجداول الزمنية، وتنفذ كل التنفيذات. هذا بسيط ويعمل جيدًا لكثير من الحالات، لكن حدوده تظهر مع زيادة الحمل:

  • كل التنفيذات تتشارك عملية Node.js واحدة تعتمد بشدة على نواة معالج واحدة.

  • تنفيذ ثقيل واحد قد يبطئ المحرر وردود الـ webhooks على الجميع.

  • لا يمكنك زيادة القدرة بإضافة عمليات أو سيرفرات.

أما queue mode ففصل استقبال العمل عن تنفيذه: تبقى النسخة الرئيسية سريعة الاستجابة، وتزيد القدرة الإنتاجية بإضافة workers. وإذا كنت لم تحسم بعد هل تحتاجه أصلًا، فدليل متطلبات تشغيل n8n يوضح أي العلامات تشير إلى سيرفر أكبر وأيها تشير إلى queue mode.

كيف تتكامل مكونات البنية؟

  • النسخة الرئيسية (main): تشغّل واجهة المحرر والـ REST API، وتسجّل الـ webhooks، وتطلق مشغّلات Schedule والاستطلاع الدوري، وتدفع مهام التنفيذ إلى Redis.

  • Redis: وسيط الرسائل. يحمل طابور المهام المنتظرة، ولا يخزن الـ workflows أو النتائج.

  • الـ Workers: عمليات n8n تبدأ بالأمر n8n worker. كل منها يأخذ مهامًا من Redis، ويحمّل الـ workflow من قاعدة البيانات، وينفذه ويحفظ التنفيذ.

  • PostgreSQL: المصدر المشترك للـ workflows وبيانات الاعتماد (credentials) وسجل التنفيذات، وكل العمليات تتصل به.

  • معالجات Webhook (اختيارية): عمليات إضافية تبدأ بالأمر n8n webhook وتستقبل طلبات الـ webhooks الإنتاجية فقط وتضعها في الطابور، لحالات الحمل الوارد الكبير جدًا.

مسار تنفيذ نموذجي: يصل طلب webhook إلى النسخة الرئيسية، فتنشئ مهمة في Redis، ويلتقطها worker متاح خلال لحظات، ينفذ الـ workflow ويكتب النتيجة في PostgreSQL، ثم يظهر التنفيذ في المحرر كأي تنفيذ آخر.

متغيرات البيئة المهمة

  • EXECUTIONS_MODE=queue على النسخة الرئيسية وعلى كل worker.

  • QUEUE_BULL_REDIS_HOST وQUEUE_BULL_REDIS_PORT وQUEUE_BULL_REDIS_PASSWORD لتصل كل العمليات إلى نفس Redis.

  • DB_TYPE=postgresdb مع متغيرات DB_POSTGRESDB_* بنفس القيم في كل مكان.

  • N8N_ENCRYPTION_KEY بنفس القيمة في كل مكان. الـ workers تفك تشفير بيانات الاعتماد به، واختلافه يعني فشل كل workflow يستخدم credentials على الـ worker.

  • QUEUE_HEALTH_CHECK_ACTIVE=true لإتاحة نقطة فحص صحة على الـ workers لأغراض المراقبة.

  • OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true لإرسال التشغيلات اليدوية من المحرر إلى الـ workers أيضًا؛ وإلا فإنها تعمل على النسخة الرئيسية. القيمة الافتراضية لهذا السلوك تغيرت بين الإصدارات.

يُضبط التوازي لكل worker عبر الخيار --concurrency، مثل n8n worker --concurrency=5، وقيمته الافتراضية 10 في الإصدارات الحالية. الأسماء والقيم الافتراضية تتغير مع الوقت، لذا راجع صفحة queue mode في توثيق n8n وملاحظات الإصدار الخاص بك.

مثال إعداد بـ Docker Compose

هذا الإعداد يشغّل PostgreSQL وRedis ونسخة رئيسية وخدمة workers قابلة للتوسع على سيرفر واحد. ضع reverse proxy مع TLS أمام المنفذ 5678 كما يشرح دليل تشغيل n8n على سيرفرك الخاص للإنتاج.

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data

  redis:
    image: redis:7
    restart: unless-stopped
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}"]
    volumes:
      - redis_data:/data

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    environment: &n8n-env
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: "6379"
      QUEUE_BULL_REDIS_PASSWORD: ${REDIS_PASSWORD}
      QUEUE_HEALTH_CHECK_ACTIVE: "true"
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS: "true"
      GENERIC_TIMEZONE: Africa/Cairo
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on: [postgres, redis]

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    command: worker --concurrency=5
    environment: *n8n-env
    depends_on: [n8n]

volumes:
  pg_data:
  redis_data:
  n8n_data:
# ملف .env (لا تضعه في نظام إدارة الإصدارات)
N8N_VERSION=x.y.z            # ثبّت الإصدار الذي اختبرته بالضبط
POSTGRES_PASSWORD=...
REDIS_PASSWORD=...
N8N_ENCRYPTION_KEY=...       # يُولَّد مرة واحدة: openssl rand -hex 32

الـ anchor في YAML يعطي الـ worker نفس بيئة النسخة الرئيسية تمامًا، فيزيل أكثر أسباب اختلاف الإعدادات شيوعًا. شغّل الإعداد ووسّع عدد الـ workers هكذا:

docker compose up -d
docker compose up -d --scale n8n-worker=3   # three worker containers
docker compose logs -f n8n-worker

لاحظ أن Redis وPostgreSQL غير منشورين على الإنترنت هنا، ولا يمكن الوصول إليهما إلا عبر شبكة Docker الداخلية. وتغطي قائمة فحص Docker Compose للإنتاج سياسات إعادة التشغيل والسجلات والتحديثات لمثل هذه البيئات.

اختياري: معالجات webhook مخصصة

إذا كانت الـ webhooks الواردة هي أغلب الحمل، شغّل عملية أو أكثر بالأمر n8n webhook بنفس متغيرات البيئة، واضبط الـ reverse proxy ليرسل مسارات /webhook/ إليها وكل ما عدا ذلك إلى النسخة الرئيسية. اضبط N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true على النسخة الرئيسية حتى تتوقف عن معالجة الـ webhooks الإنتاجية بنفسها. أما webhooks الاختبار تحت /webhook-test/ فتظل تذهب إلى النسخة الرئيسية لأنها مرتبطة بجلسة المحرر.

متى تنتقل إلى queue mode؟

  • نواة معالج واحدة عند 100% في أوقات الضغط بينما بقية الأنوية خاملة.

  • المحرر يصبح بطيئًا كلما عملت workflows كبيرة.

  • دفعات الـ webhooks تسبب انتهاء مهلة أو ردودًا بطيئة.

  • تنفيذات طويلة، مثل وكلاء الذكاء الاصطناعي التي تنتظر رد واجهات النماذج، تعطل التنفيذات القصيرة.

  • تريد إعادة تشغيل أو تحديث قدرة التنفيذ دون إيقاف المحرر.

إذا لم ينطبق شيء من ذلك، فالوضع العادي مع PostgreSQL وحد معقول للتوازي أبسط في التشغيل.

أخطاء شائعة

  • اختلاف مفاتيح التشفير: إذا ولّد worker مفتاحه الخاص فلن يستطيع فك تشفير بيانات الاعتماد. اضبط N8N_ENCRYPTION_KEY صراحة على كل عملية واحتفظ بنسخة منه.

  • SQLite: يحتاج queue mode قاعدة بيانات تتشاركها كل العمليات بأمان؛ استخدم PostgreSQL.

  • الملفات على نظام الملفات المحلي: ينص توثيق n8n على أن وضع filesystem لتخزين الملفات غير مدعوم في queue mode، لأن الملف الذي تكتبه عملية قد لا يكون مرئيًا لعملية أخرى. استخدم خيار التخزين الذي يوثقه إصدارك لـ queue mode، مثل تخزين خارجي متوافق مع S3.

  • اختلاف الإصدارات: يجب أن تعمل النسخة الرئيسية وكل الـ workers بنفس إصدار n8n، فحدّثها معًا.

  • العقد المجتمعية (Community nodes): العقد المثبتة من المحرر يجب أن تكون متاحة للـ workers أيضًا، وإلا تفشل التنفيذات التي تستخدمها هناك.

  • Redis مكشوف: لا تنشر المنفذ 6379 على الإنترنت أبدًا، واضبط كلمة مرور دائمًا.

  • عنوان webhook خاطئ: خلف الـ proxy اضبط WEBHOOK_URL ليولّد n8n روابط عامة بنطاقك وبـ HTTPS.

مراقبة الطابور

راقب شيئين: استهلاك المعالج والذاكرة لدى الـ workers، وعدد المهام المنتظرة. تراكم متزايد باستمرار يعني أنك تحتاج workers أكثر أو توازيًا أعلى، بينما workers خاملة وطابور فارغ يعنيان أن لديك هامشًا. مع البادئة الافتراضية لطابور n8n يمكنك قراءة التراكم من Redis مباشرة:

docker compose exec redis redis-cli -a "$REDIS_PASSWORD" LLEN bull:jobs:wait

أسماء المفاتيح قد تختلف بين الإصدارات. ويمكن لـ n8n أيضًا إتاحة مقاييس Prometheus عبر N8N_METRICS=true، بما فيها مقاييس الطابور في الإصدارات الحديثة.

أسئلة شائعة

هل يحتاج queue mode في n8n إلى Redis؟

نعم. Redis هو الوسيط الذي ينقل المهام من النسخة الرئيسية إلى الـ workers، ويلزم PostgreSQL أيضًا كقاعدة بيانات مشتركة.

هل يمكن تشغيل الـ workers على نفس سيرفر النسخة الرئيسية؟

نعم، وهذا هو الإعداد المعتاد على سيرفر واحد. ويمكن تشغيلها على أجهزة أخرى طالما تصل إلى Redis وPostgreSQL بشكل آمن.

كم worker أبدأ به؟

ابدأ بواحد أو اثنين بتوازي معتدل مثل 5، ثم وسّع حسب استهلاك المعالج وتراكم الطابور في ساعات الذروة.

هل queue mode ميزة مدفوعة؟

وضع queue mode متاح في n8n المستضاف ذاتيًا. أما تشغيل عدة نسخ رئيسية للتوافر العالي (multi-main) فميزة منفصلة مرتبطة بترخيص n8n للمؤسسات.

queue mode على استضافة n8n من IM HOST

تتضمن استضافة n8n من IM HOST وضع queue mode مع Redis workers في خطة Pro وما فوقها، على سيرفر KVM مخصص بأقراص NVMe مع أحدث إصدار من n8n وPostgreSQL مثبتين لك. تحصل على صلاحيات root كاملة لضبط توازي الـ workers، ونسخ احتياطي يومي مجاني، وعدد غير محدود من الـ workflows والتنفيذات. السيرفرات متوفرة في ألمانيا وبولندا وبريطانيا وأمريكا ومصر، والمتوفر حاليًا معروض في صفحة مراكز البيانات.

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات