הגדרת משימות רקע: Sidekiq, Celery, BullMQ

תארו לעצמכם: בקשת ה-HTTP שלכם לא רק מחזירה תשובה אלא גם שולחת מיילים, מייצרת קובצי PDF, ומסתנכרנת עם ממשקי API חיצוניים. זמן התגובה גדל, והלקוח מקבל timeout. הפתרון הוא להעביר משימות אלה לתורי רקע. הניסיון שלנו ביישום Sidekiq, Celery ו-BullMQ מראה שזה מפחית את זמן התגובה עד פי 5, מונע אובדן נתונים בזמן כשלים, וחוסך עד 60% ממשאבי השרת.

בפרויקט Django אחד, החלפנו שליחת מיילים סינכרונית ב-Celery. עם 10,000 מנויים, זמן התגובה ירד מ-30 שניות ל-200 אלפיות השנייה, ועומס מסד הנתונים ירד פי 4. עלות התחזוקה נחתכה בחצי עקב צריכת CPU וזיכרון נמוכה יותר. תוצאות כאלה אופייניות לעיבוד רקע מוגדר כראוי.

איך לבחור בין Sidekiq, Celery ו-BullMQ?

הבחירה תלויה בסטack שלכם ובדרישות האמינות. Sidekiq הוא הסטנדרט ל-Ruby/Rails, רץ על Redis, תומך בניסיונות חוזרים ובלוח זמנים. Celery הוא broker אוניברסלי ל-Python (תומך ב-Redis, RabbitMQ, SQS). BullMQ הוא orchestrator מודרני ל-Node.js עם משימות חוזרות מובנות. השווינו אותם לפי פרמטרים מרכזיים:

BullMQ מעבד משימות קטנות 20% מהר יותר מ-Celery בזכות מנוע ה-async שלו, אבל לתהליכי ETL מורכבים, Celery עם Redis נשאר בחירה אמינה. Sidekiq הוא האפשרות הטובה ביותר עבור מערכת Rails.

מה כלול בהגדרת תור?

אנחנו מכינים חבילה מלאה:

• הגדרת Broker (Redis, RabbitMQ, SQS) עם אופטימיזציה של זיכרון ושמירה.
• קוד Worker עם טיפול נכון בשגיאות, מדיניות ניסיונות חוזרים (exponential backoff, max_retries), ו-idempotency.
• ניטור (Sidekiq Web, Flower, BullBoard) עם אימות בסיסי.
• התראות (אינטגרציה עם Sentry, Telegram) על כשלי תור.
• תיעוד להפעלה וסקיילינג.
• הדרכת צוות: איך להוסיף משימה חדשה, איך לנפות באגים ב-workers.

כל הפתרונות נבדקים תחת עומס — אנחנו מבטיחים שהתור לא יאבד הודעה או יפיל את השרת.

איך אנחנו עושים את זה: דוגמה עם Celery

לאחרונה, העברנו פרויקט Django מ-cron jobs ל-Celery + Redis. במקור, מיילי digest גרמו ל-timeouts עם 1,000 משתמשים. אחרי יישום Celery עם celery-beat ו-Flower:

# celery.py
from celery import Celery
from celery.schedules import crontab

app = Celery('myapp')
app.config_from_object('django.conf:settings', namespace='CELERY')

# settings.py
CELERY_BROKER_URL = 'redis://redis:6379/0'
CELERY_RESULT_BACKEND = 'redis://redis:6379/1'
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_EXPIRES = 3600
CELERY_WORKER_PREFETCH_MULTIPLIER = 1

CELERY_BEAT_SCHEDULE = {
    'send-daily-digest': {
        'task': 'myapp.tasks.send_daily_digest',
        'schedule': crontab(hour=9, minute=0),
    },
    'cleanup-tokens': {
        'task': 'myapp.tasks.cleanup_expired_tokens',
        'schedule': crontab(minute=0),
    },
}

תוצאה: זמן יצירת ה-digest ירד מ-120 שניות ל-3 שניות (המשתמש לא מחכה). עומס מסד הנתונים ירד פי 4 בזכות פעולות אצווה ב-worker. התיעוד הרשמי של Celery ממליץ להשתמש ב-prefetch_multiplier=1 כדי להבטיח חלוקה שווה.

תהליך

1. ביקורת — ניתוח הארכיטקטורה הנוכחית, העומס, צווארי בקבוק.
2. עיצוב — בחירת תור, סכמת עדיפויות, מדיניות ניסיונות חוזרים.
3. פיתוח — כתיבת workers, הגדרת ניטור והתראות.
4. בדיקות — בדיקות עומס (10,000+ משימות) והתאוששות מכשלים.
5. פריסה — CI/CD, קונטיינריזציה (Docker), תיעוד.

לוח זמנים ועלות

הגדרה בסיסית של תור אחד עם worker אחד: מיום אחד. פרויקט מלא עם לוח זמנים, ניטור והתראות: 3–4 ימים. העלות מחושבת באופן אישי אחרי ביקורת. הזמינו ייעוץ — נעריך את הפרויקט שלכם.

למה idempotency היא המפתח לאמינות?

ביצוע חוזר של משימה עקב כשל יכול להוביל לחיובים כפולים או כפילויות. אנחנו מיישמים idempotency: לכל משימה יש מזהה ייחודי, וה-worker בודק את המצב לפני הביצוע. זה מבטל עיבוד כפול גם עם ניסיונות חוזרים. בניסיון שלנו — 0 מקרי כפילות נתונים על 50+ פרויקטים.

טעויות אופייניות ביישום

• אין idempotency — משימה שחוזרת שוברת את הלוגיקה העסקית.
• יותר מדי ניסיונות חוזרים — התור נסתם בהודעות מתות.
• התעלמות מניטור — משימה נכשלת ואתם מגלים רק אחרי שבוע.
• קריאות סינכרוניות ב-worker — חוסמות את Eventlet.

אנחנו מבטיחים שסטack משימות הרקע שלכם ירוץ ביציבות ויתקפל בלי הפתעות. ניסיון מצטבר: 8+ שנות יישומים.

הגדרת Sidekiq (Ruby/Rails)

Sidekiq משתמש ב-Redis כאחסון התור, תומך בניסיונות חוזרים, משימות מתות, ולוח זמנים.

# Gemfile
gem 'sidekiq', '~> 7.0'
gem 'sidekiq-scheduler'

# config/sidekiq.yml
:concurrency: 10
:queues:
  - [critical, 5]
  - [default, 3]
  - [mailers, 2]
  - [low, 1]

# app/workers/email_worker.rb
class EmailWorker
  include Sidekiq::Job
  sidekiq_options queue: :mailers, retry: 3, backtrace: true

  def perform(user_id, template, variables = {})
    user = User.find(user_id)
    UserMailer.send(template, user, variables).deliver_now
  end
end

# Вызов
EmailWorker.perform_async(user.id, :welcome)
EmailWorker.perform_in(5.minutes, user.id, :follow_up)
EmailWorker.perform_at(1.day.from_now, user.id, :follow_up)

הגדרת Celery (Python/Django)

# tasks.py
from celery import shared_task
from myapp.models import User
from myapp.services import send_email

@shared_task(
    bind=True,
    max_retries=3,
    default_retry_delay=60,
    queue='emails',
)
def send_welcome_email(self, user_id: int) -> dict:
    try:
        user = User.objects.get(pk=user_id)
        send_email(user.email, 'welcome', {'name': user.first_name})
        return {'status': 'sent', 'user_id': user_id}
    except Exception as exc:
        raise self.retry(exc=exc, countdown=2 ** self.request.retries * 60)

# Вызов send_welcome_email.delay(user.id)
send_welcome_email.apply_async(args=[user.id], countdown=300)

---
# docker-compose: воркеры Celery
celery-worker:
  build: .
  command: celery -A myapp worker --loglevel=info --concurrency=4 -Q emails,default
  depends_on: [redis, db]
  environment: *app_env
celery-beat:
  build: .
  command: celery -A myapp beat --loglevel=info --scheduler django_celery_beat.schedulers:DatabaseScheduler
  depends_on: [redis, db]
celery-flower:
  build: .
  command: celery -A myapp flower --port=5555 --basic-auth=admin:password
  ports:
    - "5555:5555"

ניטור Sidekiq

# config/routes.rb
require 'sidekiq/web'

authenticate :user, ->(u) { u.admin? } do
  mount Sidekiq::Web => '/sidekiq'
end

Flower עבור Celery זמין בפורט 5555. מציג משימות, workers, עיכובים, ניסיונות חוזרים.

השוואת כלי ניטור

צרו קשר לביקורת על הפרויקט שלכם — קבלו ייעוץ על בחירת תור והגדרה. פנו אלינו ליישום משימות רקע — השרת שלכם יפסיק לחכות.