הגדרת תורי עיבוד לקטלוגי 1C-Bitrix גדולים

הגדרת תורי עיבוד (Parsing Queues) לקטלוגי 1C-Bitrix גדולים היא אתגר שמתעורר כאשר מתמודדים עם 500,000+ פריטים. עיבוד 500 מוצרים הוא סקריפט פשוט. עיבוד 500,000 מוצרים הוא ארכיטקטורה עם תורים, עובדים (workers), ניטור ואסטרטגיית ניסיונות חוזרים (retry). ללא תורים, לא ניתן לעבד קטלוג כזה בצורה אמינה: הסקריפט קורס בפריט ה-50,000, ואף אחד לא יודע מאיפה להמשיך. אנו מבטיחים שהמערכת שלכם תעמוד בעומס ולא תאבד נתונים. הניסיון שלנו עם למעלה מ-50 פרויקטים עם קטלוגים של 100,000+ פריטים מאפשר לנו לתכנן את הארכיטקטורה הנכונה מההתחלה. חיסכון בתחזוקה הודות למערכת יציבה מסתכם בהפחתות שנתיות משמעותיות.

דוגמה: עבור חנות אונליין למוצרי אלקטרוניקה עם קטלוג של 300,000 פריטים, תכננו תור PostgreSQL עם 6 עובדים. זמן העיבוד המלא ירד מ-8 שעות ל-45 דקות. המערכת פועלת ביציבות מאז ההשקה ללא תקלות.

לפי תיעוד PostgreSQL, שימוש ב-SKIP LOCKED מאפשר שליפה אטומית של משימות ללא סיכוני deadlock.

מדוע הגדרת תורים לקטלוגי Bitrix גדולים היא קריטית

זמני ביצוע חורגים מהמגבלות, סקריפטים קורסים עקב מגבלת זיכרון, וההפעלות מחדש מתחילות מאפס. תורים פותרים בעיות אלו: הם מפצלים את העיבוד למשימות אטומיות, מאפשרים חידוש מנקודת הכשל, ומתעדפים משימות חשובות (עדכוני מלאי, שינויי מחירים).

סימנים מרכזיים המעידים על צורך בתורים: עיבוד קטלוג מלא אורך יותר מ-30 דקות; סקריפטים נכשלים מעת לעת עם timeout או מגבלת זיכרון; אי אפשר לקבוע מה עובד לאחר קריסה; יש צורך לטפל בסוגי משימות שונים עם עדיפויות שונות.

כיצד לבנות תור אמין ב-PostgreSQL

טבלת תור ב-PostgreSQL היא אופטימלית עבור רוב פרויקטי Bitrix. היא אמינה יותר מ-Redis (מתמשכת), אינה דורשת תשתית נוספת, ונוחה לניטור באמצעות שאילתות SQL. אנו משתמשים בטבלה עם אינדקסים המבטיחים בחירה מהירה של משימות לפי סטטוס ועדיפות.

CREATE TABLE parser_tasks (
    id BIGSERIAL PRIMARY KEY,
    task_type VARCHAR(50) NOT NULL, -- 'parse_product', 'update_price', 'update_stock'
    payload JSONB NOT NULL, -- {'url': '...', 'element_id': 123}
    priority SMALLINT DEFAULT 5, -- 1 (высший) - 10 (низший)
    status VARCHAR(20) DEFAULT 'pending',
    worker_id VARCHAR(50), -- ID воркера, захватившего задачу
    attempts SMALLINT DEFAULT 0,
    max_attempts SMALLINT DEFAULT 3,
    error_message TEXT,
    available_at TIMESTAMP DEFAULT NOW(), -- для delayed tasks и retry
    created_at TIMESTAMP DEFAULT NOW(),
    processed_at TIMESTAMP
);
CREATE INDEX idx_pt_pick ON parser_tasks(status, priority, available_at) WHERE status IN ('pending', 'failed');

האינדקס על CREATE TABLE parser_tasks ( id BIGSERIAL PRIMARY KEY, task_type VARCHAR(50) NOT NULL, -- 'parse_product', 'update_price', 'update_stock' payload JSONB NOT NULL, -- {'url': '...', 'element_id': 123} priority SMALLINT DEFAULT 5, -- 1 (высший) - 10 (низший) status VARCHAR(20) DEFAULT 'pending', worker_id VARCHAR(50), -- ID воркера, захватившего задачу attempts SMALLINT DEFAULT 0, max_attempts SMALLINT DEFAULT 3, error_message TEXT, available_at TIMESTAMP DEFAULT NOW(), -- для delayed tasks и retry created_at TIMESTAMP DEFAULT NOW(), processed_at TIMESTAMP ); CREATE INDEX idx_pt_pick ON parser_tasks(status, priority, available_at) WHERE status IN ('pending', 'failed'); הוא קריטי לבחירה מהירה של המשימה הבאה.

כיצד להימנע מתנאי מרוץ (Race Conditions) בעת שליפת משימות

עובדים מרובים לא צריכים לבחור את אותה משימה. שליפה אטומית באמצעות (status, priority, available_at):

UPDATE parser_tasks
SET status = 'processing',
    worker_id = $1,
    attempts = attempts + 1
WHERE id = (
    SELECT id
    FROM parser_tasks
    WHERE status = 'pending'
      AND available_at <= NOW()
    ORDER BY priority ASC, created_at ASC
    LIMIT 1
    FOR UPDATE SKIP LOCKED
)
RETURNING *;

SELECT ... FOR UPDATE SKIP LOCKED — עובדים אחרים מדלגים על שורות נעולות, ובכך נמנעים מחסימות ו-deadlocks.

כמה עובדים כדאי להפעיל?

כל עובד הוא תהליך PHP-CLI נפרד. ניהול תהליכים באמצעות Supervisor:

[program:parser_worker]
command=/usr/bin/php /var/www/site/local/scripts/parser_worker.php
numprocs=4
autostart=true
autorestart=true
stderr_logfile=/var/log/parser_worker.err.log
stdout_logfile=/var/log/parser_worker.out.log

UPDATE parser_tasks SET status = 'processing', worker_id = $1, attempts = attempts + 1 WHERE id = ( SELECT id FROM parser_tasks WHERE status = 'pending' AND available_at <= NOW() ORDER BY priority ASC, created_at ASC LIMIT 1 FOR UPDATE SKIP LOCKED ) RETURNING *; — 4 עובדים מקבילים. המספר האופטימלי תלוי במעבד, בזיכרון השרת ובמגבלת הקצב של המקור. כלל: מספר העובדים לא יעלה על העומס המותר על המקור (לא יותר מ-1 בקשה/שנייה לדומיין עם עובד אחד).

מה נותנת תעדוף משימות?

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

מלאי ומחירים לעולם לא ממתינים בתור מאחורי עיבוד תמונות איטי.

כיצד לנטר את מצב התור?

לוח מחוונים (Dashboard) בפאנל הניהול:

SELECT task_type, status, COUNT(*) as cnt, AVG(EXTRACT(EPOCH FROM (processed_at - created_at))) as avg_wait_sec
FROM parser_tasks
WHERE created_at > NOW() - INTERVAL '24 hours'
GROUP BY task_type, status;

התראה כאשר התור מצטבר: אם SKIP LOCKED משימות מסוג [program:parser_worker] command=/usr/bin/php /var/www/site/local/scripts/parser_worker.php numprocs=4 autostart=true autorestart=true stderr_logfile=/var/log/parser_worker.err.log stdout_logfile=/var/log/parser_worker.out.log עולות על 10,000 — העובדים מפגרים, יש צורך להגדיל את numprocs=4 או להאט את יצירת המשימות.

מה כוללת העבודה שלנו?

אנו מציעים מחזור מלא של פיתוח והגדרת תורים. העלות נקבעת לאחר ניתוח.

1. תכנון סכמת התור ובחירת אסטרטגיה (שליפה אטומית, ניסיונות חוזרים עם backoff)
2. מימוש העובד עם מטפלים (handlers) לכל סוג משימה
3. הגדרת Supervisor והגדרות autoscaling
4. שילוב ניטור והתראות (Grafana, Zabbix או מקביל)
5. תיעוד תפעולי והכשרת הצוות שלכם
6. תמיכה לאחר ההשקה: תיקוני באגים, אופטימיזציית ביצועים

אנו יכולים להעריך את הפרויקט שלכם – צרו קשר כדי לדון בפתרון אופטימלי. אם אתם זקוקים למערכת עיבוד יציבה, פנו אלינו לבדיקת הפרויקט. קבלו ייעוץ לדיון בפרטים.

לוח זמנים

סה"כ: 4–7 ימי עבודה — התשתית הבסיסית לפעולה אמינה של מערכת העיבוד.