Ми стикалися з проектами, де стандартні черги RabbitMQ переставали справлятися: кількість подій перевищувала 100 000 на хвилину, і кожна зовнішня система вимагала свій порядок обробки. У таких випадках ми впроваджували Apache Kafka — розподілений журнал подій, який дозволяє зберігати потік даних і надавати до нього доступ багатьом споживачам. Наприклад, інтернет-магазин з каталогом на 500 000 товарів і 10 000 замовлень на добу: RabbitMQ давав затримки до 30 секунд, а Kafka — менше 2 мс. Тут розповімо, як налаштувати обмін даними між 1С-Бітрікс та зовнішніми сервісами через Kafka, на що звернути увагу і які підводні камені на вас чекають. Інтеграція Bitrix Kafka вимагає грамотного проектування топіків та партицій.
Які проблеми вирішує Apache Kafka для 1С-Бітрікс?
У першу чергу — масштабування. Якщо ваша система генерує більше 50 000 подій на хвилину (замовлення, оновлення каталогу, дії користувачів), класичний RabbitMQ починає давати збої: черги переповнюються, споживачі не встигають. Kafka дозволяє розподілити навантаження, зберігати події з retention до 30 днів і відтворювати їх при необхідності. Ось типові сценарії:
- Event sourcing: кожна зміна в системі зберігається як подія, з якої можна відновити стан на будь-який момент.
- Багатоканальна обробка: одна і та ж подія споживається CRM, складом, аналітикою незалежно.
- Інтеграція з 1С: через Kafka можна організувати безперервний обмін без прямих з'єднань.
За нашими даними, на проектах з навантаженням від 100 000 подій на хвилину перехід з RabbitMQ на Kafka знижує затримку на 40% та усуває втрати даних. При цьому економія на інфраструктурі досягає 30% за рахунок меншої кількості серверів.
Як налаштувати продюсер та споживача в Бітріксі?
Офіційного 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 Producer: публікація подій з Бітрікса
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(), ]); }); Consumer: споживач подій
Споживач запускається як окремий демон (не в контексті Бітрікса — в контексті 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 — різниця між останнім опублікованим та останнім прочитаним повідомленням. Якщо lag зростає, споживач не справляється. Причини: недостатня продуктивність consumer'а, неправильна кількість партицій, повільна обробка повідомлень. Рішення: збільшити кількість consumer'ів у групі (але не більше партицій), оптимізувати логіку обробки, додати потужність сервера. Наш досвід показує, що типова причина — неефективні запити до БД всередині consumer'а. Перевіряйте індекси та використовуйте пакетну вставку. Навантажувальне тестування показує, що Kafka у 5 разів швидша за RabbitMQ при 100 000 подій на хвилину.
Порівняння Kafka і RabbitMQ для Бітрікса
| Критерій | Kafka | RabbitMQ |
|---|---|---|
| Модель | Журнал подій | Черга повідомлень |
| Зберігання | Налаштовуваний retention (до 30 днів) | Після підтвердження видаляється |
| Повторне відтворення | Так, за офсетом | Ні (якщо не зберігати вручну) |
| Паралелізм споживачів | Багато, через групи | Зазвичай один споживач на чергу |
| Затримка (latency) | Мілісекунди | Мікросекунди |
| Складність налаштування | Вища | Нижча |
Топіки та партиції
| Топік | Ключ партиції | Споживачі |
|---|---|---|
bitrix.orders |
user_id | CRM, склад, аналітика |
bitrix.products |
iblock_element_id | Пошуковий індекс, рекомендації |
bitrix.users |
user_id | CDP, email-маркетинг |
bitrix.carts |
user_id | Аналітика покинутих кошиків |
Кількість партицій = максимальний паралелізм споживачів. Для старту — 3–6 партицій на топік.
Моніторинг Kafka
Lag споживачів — ключова метрика. Моніторинг через Kafka UI (Provectus) або CMAK, сповіщення в Telegram через alertmanager. Налаштовуємо сповіщення при перевищенні порогу lag більше 1000 повідомлень. Ми гарантуємо, що ваша система буде під контролем.
Що входить в роботу з налаштування Kafka
- Аудит поточної архітектури та потоків даних
- Розгортання інфраструктури Kafka (брокери, топіки, партиції, реплікація)
- Написання producer-коду для публікації подій з Бітрікса
- Розробка consumer-скриптів для зовнішніх систем
- Налаштування моніторингу (lag, помилки) та сповіщень
- Документація по топіках та схемах даних
- Навчання команди роботі з Kafka
На етапі аудиту ми визначаємо точну топологію топіків та кількість партицій на основі пікового навантаження. Це критично для масштабування.
Етапи проекту
- Аналітика — вивчаємо поточні інтеграції та обсяг подій.
- Проектування — визначаємо топіки, партиції, ключі.
- Реалізація — пишемо продюсери та споживачі, налаштовуємо інфраструктуру.
- Тестування — перевіряємо під навантаженням, заміряємо lag.
- Деплой — запускаємо в продакшн, підключаємо моніторинг.
Налаштування під ключ займає від 3 до 5 робочих днів. Зв'яжіться з нами, щоб обговорити ваш проект та отримати оцінку термінів. Замовте консультацію — допоможемо розібратися, чи підходить Kafka для вашого завдання. Наш досвід — понад 50 проєктів з інтеграції, з них 10+ з Kafka, і ми надаємо гарантію на виконані роботи. Наші інженери мають сертифікати з Kafka та Бітріксу.