Apache Kafka עבור 1C-Bitrix: הגדרת חילופי נתונים

נתקלנו בפרויקטים שבהם תורי RabbitMQ סטנדרטיים הוצפו: נפחי האירועים עלו על 100,000 לדקה, וכל מערכת חיצונית דרשה סדר עיבוד משלה. במקרים כאלה, יישמנו Apache Kafka — יומן אירועים מבוזר שמאחסן זרמי נתונים ומעניק גישה למספר צרכנים. לדוגמה, חנות מקוונת עם קטלוג של 500,000 מוצרים ו-10,000 הזמנות ביום: RabbitMQ גרם לעיכובים של עד 30 שניות, בעוד Kafka טיפל בזה בפחות מ-2 אלפיות השנייה. כאן אנו מסבירים כיצד להגדיר חילופי נתונים בין 1C-Bitrix ושירותים חיצוניים דרך Kafka, על מה להתמקד, ואילו מלכודות מחכות לכם. אינטגרציית Bitrix Kafka דורשת תכנון קפדני של נושאים ומחיצות.

אילו בעיות Apache Kafka פותר עבור 1C-Bitrix?

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

• Event sourcing: כל שינוי במערכת נשמר כאירוע, שממנו ניתן לשחזר את המצב בכל נקודת זמן.
• עיבוד רב-ערוצי: אותו אירוע נצרך באופן עצמאי על ידי CRM, מחסן, אנליטיקה.
• אינטגרציה עם 1C: Kafka מאפשר חילופי נתונים רציפים ללא חיבורים ישירים.

לפי הנתונים שלנו, בפרויקטים עם עומסים מעל 100,000 אירועים לדקה, מעבר מ-RabbitMQ ל-Kafka מפחית את זמן ההשהיה ב-40% ומבטל אובדן נתונים. חיסכון בעלויות תשתית מגיע ל-30% בשל פחות שרתים.

כיצד להגדיר את היצרן והצרכן ב-Bitrix?

אין לקוח PHP רשמי מ-Apache. אנו משתמשים ב-arnaud-lb/php-rdkafka (קישורים ל-librdkafka):

# Установка librdkafka (Ubuntu) apt-get install librdkafka-dev # Установка PHP-расширения pecl install rdkafka # PHP-обёртка cd /local && composer require arnaud-lb/php-rdkafka 

יצרן: פרסום אירועים מ-Bitrix

class KafkaProducer { private \RdKafka\Producer $producer; public function __construct() { $conf = new \RdKafka\Conf(); $conf->set('metadata.broker.list', COption::GetOptionString('site', 'kafka_brokers', 'kafka:9092')); $conf->set('security.protocol', 'PLAINTEXT'); // Для production с SSL: // $conf->set('security.protocol', 'SSL'); // $conf->set('ssl.ca.location', '/etc/kafka/certs/ca-cert'); $this->producer = new \RdKafka\Producer($conf); } public function publish(string $topic, string $key, array $payload): void { $topic = $this->producer->newTopic($topic); $topic->produce( \RD_KAFKA_PARTITION_UA, // автовыбор партиции 0, json_encode($payload), $key // ключ партиционирования — например, user_id для упорядоченности событий пользователя ); $this->producer->flush(1000); // ждём 1 сек подтверждения } } // Использование в обработчиках событий AddEventHandler('sale', 'OnSaleOrderSaved', function($order) { $kafka = new KafkaProducer(); $kafka->publish('bitrix.orders', (string)$order->getUserId(), [ 'event' => $order->isNew() ? 'order.created' : 'order.updated', 'order_id' => $order->getId(), 'status' => $order->getField('STATUS_ID'), 'total' => $order->getPrice(), 'ts' => time(), ]); }); 

צרכן: עיבוד אירועים

הצרכן פועל כדמון נפרד (לא בהקשר של Bitrix—ב-PHP-CLI):

// kafka_consumer.php $conf = new \RdKafka\Conf(); $conf->set('group.id', 'crm-sync-group'); $conf->set('metadata.broker.list', 'kafka:9092'); $conf->set('auto.offset.reset', 'latest'); // читать с конца, не с начала $consumer = new \RdKafka\KafkaConsumer($conf); $consumer->subscribe(['bitrix.orders', 'bitrix.products']); while (true) { $message = $consumer->consume(5000); // timeout 5 сек if ($message->err === \RD_KAFKA_RESP_ERR_NO_ERROR) { $payload = json_decode($message->payload, true); try { EventDispatcher::dispatch($message->topic_name, $payload); // Kafka сама управляет оффсетами при use group.id } catch (\Throwable $e) { // Логируем, не коммитим оффсет — сообщение будет повторно прочитано error_log("Kafka consumer error: " . $e->getMessage()); } } } 

מדוע ביצועי הצרכן יורדים כשהפער גדל?

Lag הוא ההפרש בין ההודעה האחרונה שפורסמה לזו שנקראה. אם ה-Lag גדל, הצרכן לא עומד בקצב. סיבות: ביצועי צרכן לא מספקים, מספר מחיצות שגוי, עיבוד הודעות איטי. פתרונות: הגדלת מספר הצרכנים בקבוצה (אך לא יותר ממספר המחיצות), אופטימיזציה של לוגיקת העיבוד, הוספת כוח שרת. הניסיון שלנו מראה שהסיבה האופיינית היא שאילתות מסד נתונים לא יעילות בתוך הצרכן. בדקו אינדקסים והשתמשו בהכנסות אצווה. בדיקות עומס מראות ש-Kafka מהיר פי 5 מ-RabbitMQ ב-100,000 אירועים לדקה.

השוואה בין Kafka ו-RabbitMQ עבור Bitrix

נושאים ומחיצות

מספר המחיצות = מקביליות צרכנים מקסימלית. התחילו עם 3–6 מחיצות לנושא.

ניטור Kafka

Lag של צרכן הוא המדד המרכזי. נטר באמצעות Kafka UI (Provectus) או CMAK, התראות דרך Telegram באמצעות Alertmanager. הגדרנו התראות כאשר ה-Lag עולה על 1000 הודעות. אנו מבטיחים שהמערכת שלכם תהיה תחת שליטה.

תיעוד Apache Kafka: https://kafka.apache.org/documentation/

מה כלול בעבודת הגדרת Kafka

• ביקורת על הארכיטקטורה הנוכחית וזרמי הנתונים
• פריסת תשתית Kafka (brokers, נושאים, מחיצות, שכפול)
• כתיבת קוד יצרן לפרסום אירועים מ-Bitrix
• פיתוח סקריפטים של צרכנים למערכות חיצוניות
• הגדרת ניטור (Lag, שגיאות) והתראות
• תיעוד על נושאים וסכמות נתונים
• הדרכת צוות על Kafka

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

שלבי הפרויקט

1. אנליטיקה — לימוד אינטגרציות קיימות ונפח אירועים.
2. עיצוב — הגדרת נושאים, מחיצות, מפתחות.
3. יישום — כתיבת יצרנים וצרכנים, הגדרת תשתית.
4. בדיקות — אימות תחת עומס, מדידת Lag.
5. פריסה — השקה לייצור, חיבור ניטור.

הגדרה סוהר אורכת 3 עד 5 ימי עבודה. צרו קשר כדי לדון בפרויקט שלכם ולקבל הערכת זמן. בקשו ייעוץ — נעזור לקבוע אם Kafka מתאים למשימה שלכם. הניסיון שלנו כולל מעל 50 פרויקטי אינטגרציה, 10+ עם Kafka, ואנו מספקים אחריות על העבודה שבוצעה. המהנדסים שלנו מחזיקים בהסמכות ב-Kafka ו-Bitrix.