Налаштування MongoDB Change Streams для подієво-орієнтованої архітектури

Change Streams MongoDB: де ламається потік змін

Типова схема виглядає так: сервіси читають не основну базу, а копію, яку оновлюють за розкладом — раз на годину або вночі. Між реальною зміною та її появою в копії лежить вікно, і все, що відбувається всередині нього, сервіси просто не бачать.

Поки навантаження мале, це непомітно; на потоці замовлень, залишків або статусів розбіжності починають накопичуватися.

Ціна — застарілі дані в сервісах: клієнт бачить товар у наявності, якого вже немає, статус заявки відстає на кілька кроків, звітність рахує за вчорашнім зрізом.

Такі проблеми синхронізації баз даних підступні тим, що відтворюються не завжди і не в одного користувача, тому їх списують на кеш або на «плаваючий» дефект. Далі ламається вже бізнес-логіка, а не окремий екран.

Найдорожче починається під час розбору інциденту. Потрібно зрозуміти, яка саме зміна не доїхала і в який момент, — а журналу немає, є лише два зрізи, які не збігаються. Далі ручне звіряння даних: вивантаження, порівняння за ключами, пошук розбіжностей очима. На це йдуть дні роботи інженерів, і повторний збій все одно не виключений.

Change Streams MongoDB закривають цю діру інакше: база сама віддає підписнику неперервний потік змін MongoDB — вставки, оновлення, видалення — у міру їх появи, без опитування за розкладом.

У потоку є точка відновлення, тому після перезапуску сервіс продовжує з того місця, де зупинився, а не з нічного зрізу. Нижче розбираємо, де такий потік ламається на практиці і що робимо, щоб він не втрачав події.

Що дає підписка на зміни: вимірюваний ефект

Підписка на зміни MongoDB перетворює базу з джерела, яке доводиться опитувати, на джерело подій. Нижче — що змінюється в експлуатації, коли синхронізація даних у реальному часі та подієва архітектура будуються на цьому механізмі.

Затримка реакції — секунди замість хвилин

Раніше синхронізація йшла опитуванням за розкладом: між записом і появою даних у вітрині, пошуку або сповіщенні минали хвилини.

Підписка на зміни MongoDB віддає подію одразу після фіксації запису, тому відставання вимірюється частками секунди, а період опитування більше не задає точність системи.

Навантаження на основну базу падає на порядок

Опитування «щось змінилося?» б'є по базі постійно, і кожен новий споживач додає свої запити.

Підписка читає журнал операцій один раз і роздає події підписникам: кількість звернень до основної бази перестає зростати разом із кількістю сервісів, а обробка не конкурує з клієнтським трафіком у піках.

Ручні розбори розсинхрону зникають

Відмовостійка доставка подій будується на підтвердженні обробки та збереженій позиції продовження: після перезапуску потік відновлюється з того самого місця, а повтори гасяться за ідентифікатором події. Частка інцидентів «дані розійшлися», які раніше розбирали вручну за скаргою, зводиться до нуля.

Розсинхрон видно до клієнта

У кожного потоку є метрика відставання: скільки подій ще не оброблено і як давно надійшла остання.

Клас відмов «вивантаження мовчки не доїхало» переходить із виявлення заднім числом у спостереження — оповіщення надходить, коли відставання виходить за поріг, а не коли користувач помітив розбіжність.

Режими підписки на зміни в MongoDB: порівняння підходів

У MongoDB доставку змін закриває один серверний механізм — потік змін на основі журналу операцій.

Режими підписки при цьому різні, і вони не взаємозамінні: відрізняється гранулярність потоку, місце фільтрації та те, скільки незалежних отримувачів подій тримається на одному курсорі.

Вибір зводиться до трьох питань: наскільки вузький потік потрібен споживачу, скільки отримувачів і яка затримка допустима. Далі — порівняння підходів синхронізації, між якими реально вибирають на практиці.

Часто комбінують: вузька підписка плюс проміжний журнал, якщо отримувачів кілька. Кожному споживачу — свій курсор і своя збережена позиція: повільний обробник тоді не тягне за собою інших, а після збою потік продовжується з останньої підтвердженої події.

Етапи впровадження: від аудиту до передачі в експлуатацію

Порядок робіт тут не формальність: підписка на зміни спирається на журнал операцій replica set, і якщо налаштувати її до аудиту, потік або втрачає події при переповненні журналу, або непомітно відстає на піках запису.

Тому впровадження change streams у MongoDB йде від вимірювань до навантажувальної перевірки і лише потім — в експлуатацію.

1. Аудит бази даних. Дивимося топологію replica set, темп запису, розмір і швидкість зростання журналу операцій, профіль навантаження: точкові вставки, масові оновлення, рідкісні видалення. Окремо фіксуємо, хто ще читає ті самі колекції — ці процеси ділять із потоком ресурси.
2. Схема потоку подій. Визначаємо колекції та типи операцій, що потрапляють у підписку, фільтри за умовами та полями на стороні бази. Фіксуємо формат події на виході та точку, куди вона йде: черга, обробник або сховище.
3. Налаштування підписки на зміни. Задаємо режим повного документа, зберігання токена відновлення та правила перезапуску з точки зупинки. Обробник робимо ідемпотентним — повтор події не повинен ламати стан.
4. Перевірка доставки подій. Прогоняємо наскрізний сценарій: зміна в базі → подія → обробник → результат. Дивимося поведінку при розриві з'єднання, перезапуску сервісу та навмисному дублі.
5. Навантажувальна перевірка потоку. Заміряємо затримку доставки та відставання на піковому темпі запису, перевіряємо, що відбувається при переповненні журналу. За результатами правимо розмір пакета, буфери та кількість споживачів.
6. Передача в експлуатацію. Віддаємо схему потоку, конфігурацію, метрики та пороги алертів, регламент дій при відставанні. Команда замовника бачить потік повністю і знає, куди дивитися.

Що залишається у вашої команди після впровадження

Ми не залишаємо впровадження «працюючим, але незрозумілим»: разом із налаштованим потоком змін ваша команда отримує комплект, за яким можна супроводжувати систему самостійно, а новий інженер входить у контур за пару днів.

• Конфігурації потоку змін — файли з параметрами підключення, розміром пакета вибірки, рівнем повноти документа та стратегією відновлення після розриву зв'язку. Кожне значення прокоментовано: що зміниться в поведінці, якщо його підняти або опустити.
• Схеми потоків даних — звідки надходить зміна, які етапи обробки проходить, куди записується результат і де стоїть захист від повторної доставки однієї й тієї самої події.
• Політики доступу та ролі — окремі облікові записи для читання потоку і для службових операцій, мінімально необхідні права, порядок ротації ключів.
• Документація щодо потоку змін — які колекції та поля відстежуються, як читається журнал операцій, які події вважаються службовими і відкидаються.
• Регламент експлуатації — як перевіряти відставання обробки від поточного моменту, що дивитися при обриві, які пороги потребують втручання чергового.
• Порядок відкату змін — як повернути попередню конфігурацію і зупинити споживачів, не втративши вже прочитані події.
• Набір метрик і оповіщень — затримка доставки, частка помилок обробки, кількість перепідключень.

Кожен артефакт прив'язаний до конкретної операції, а не написаний «для галочки»: за регламентом черговий розуміє, що робити при обриві, а за схемами видно, де додасться новий споживач без перегляду всієї архітектури.

Кейс: синхронізація замовлень без ручного звіряння

Клієнт — сервіс замовлень: стан змінюється в основній базі, а вітрина, склад і білінг забирали зміни періодичним опитуванням раз на п'ятнадцять хвилин.

На піках опитування не встигало, відставання сягало сорока хвилин, а при розриві з'єднання зміни губилися: черговий запит бачив уже наступний стан і «проковтував» проміжні переходи статусів.

Частка розбіжностей за активними замовленнями трималася в межах 3–5%, і щотижня підтримка вручну розбирала кілька десятків таких випадків.

Що змінили

Потік змін перевели на Change Streams MongoDB: кожен споживач підписаний на свою колекцію з фільтром за типом операції і бачить події в порядку їх виникнення.

Токен відновлення записується після обробки кожної події, тому після обриву підписник продовжує рівно з місця зупинки — без пропусків і без перечитування всієї історії. Обробку зробили ідемпотентною за ідентифікатором події, щоб повторна доставка не подвоювала списання.

Що вийшло

Відставання синхронізації на піку — одиниці секунд замість десятків хвилин, частка розбіжностей упала нижче 0,1%, ручні розбори — з десятків на тиждень до одиничних.

Стійкість перевіряли керованим обривом зв'язку: підписник сам наздоганяв пропущене, втручання чергового не було потрібне. Підписку на ті самі події отримали складський сервіс і білінг — синхронізація кількох сервісів іде від одного потоку замість трьох незалежних опитувань.

Що робити, якщо події губляться при обриві зв'язку

Події губляться не в момент обриву зв'язку з базою, а в момент перепідключення.

Якщо ідентифікатор останньої обробленої події жив у пам'яті процесу, то рестарт контейнера або перезапуск застосунку означає старт із поточного моменту — усе, що потрапило в базу за час простою, для обробників не існує. У MongoDB цей збій виглядає як «потік живий, помилок немає, а частина змін не застосувалася».

Точка відновлення потоку — це ідентифікатор події, який сервер віддає разом із кожним записом і вміє приймати назад в опціях resumeAfter і startAfter. Алгоритм простий: фіксуємо ідентифікатор лише після успішної обробки події, у надійному сховищі поруч із бізнес-даними.

Порядок «спочатку записали точку, потім обробили» дає втрату при падінні між двома кроками, зворотний порядок — повторну доставку, але ніколи не пропуск.

Відновлення потоку змін при обриві працює через журнал операцій: сервер програє накопичені зміни починаючи з переданої точки.

Проблема починається, коли пауза перевищила глибину журналу — тоді точка вважається недійсною, потік не підніметься, і потрібен холодний старт із повним звірянням стану колекції проти подій. Тому лаг обробки та глибину журналу тримають на моніторингу з алертом, а не з'ясовують постфактум.

Повторна доставка — штатна поведінка, гарантія тут «не рідше одного разу». Обробники роблять ідемпотентними: ключ події в таблиці дедуплікації або вставка-або-оновлення за природним ключем.

У тихі періоди події не надходять, і точка відновлення не рухається — її просувають за службовою міткою пакета, інакше після довгого затишшя історія знову опиниться за межами журналу і потік доведеться перестворювати.

Практика наших інженерів: точка відновлення зберігається поза процесом, обробники ідемпотентні, на лаг і строк зберігання журналу налаштовані алерти. Опишіть, як зараз влаштований потік, — повернемося з розбором слабких місць і планом правок.

Технічні сумніви: обмеження та порядок подій

Потік змін MongoDB знімає більшість питань на демо і майже всі — на рев'ю перед запуском. Від відповідей нижче залежить, чи переживе підписка падіння вузла, відставання споживача та зростання журналу змін.

Чи гарантований порядок подій?

Порядок тримається в межах одного ключа маршрутизації, а не всієї бази. Там, де важлива строга послідовність за об'єктом, прив'язуємо підписників до того самого ключа — інакше два оновлення одного документа надійдуть у різному порядку.

Що буде, якщо підписник відстав на години?

Позиція читання зберігається токеном відновлення, але вікно доступності обмежене розміром журналу змін. Як тільки позиція випадає за межу, потік не відновити — потрібна переініціалізація. Вікно тримаємо із запасом під максимальний простій.

Наскільки це навантажує базу?

Потік читає журнал змін, а не колекції, і навантажує переважно вузол читання. Виносимо підписників на репліку, задаємо окреме з'єднання та ліміти — робочі запити не конкурують з обробкою подій.

Які обмеження у самих потоків?

Потрібен режим реплікації — на одиночному вузлі підписку не підняти. Частина операцій рівня колекцій відображається не повністю, а фільтри за полями чутливі до колації. Ці місця закриваємо регулярним звірянням.

Обговоримо задачу: що надіслати для оцінки впровадження

Щоб повернутися з оцінкою впровадження, а не із загальними словами, нам потрібен зріз системи: як влаштовані дані, хто читає потік змін MongoDB і що для вас критично в його поведінці. Нижче — вступні, які закривають майже всі невідомі на старті.

• Схема колекцій і характер запису: які колекції потрапляють у потік, частка вставок, оновлень і видалень, чи є масові правки та транзакції.
• Перелік споживачів подій: сервіси, черги, пошуковий індекс, кеш, сховище аналітики — і кому потрібен повний документ, а кому достатньо ключа та типу операції.
• Вимоги до порядку подій: чи допустима повторна доставка і в якому вікні, чи потрібен строгий порядок у межах документа, що робити при пропуску.
• Поведінка при відмовах: скільки споживач може бути недоступним, чи потрібна буферизація, з якої позиції потік відновлюється після збою.
• Горизонт журналу операцій і регламент планових робіт: наскільки глибоко можна перемотати потік і що відбувається при тривалій зупинці.
• Доступи та цільові показники: ролі, мережеві обмеження, допустима затримка доставки та піковий обсяг потоку.

Надішліть те, що є: схеми колекцій, список споживачів, поточні регламенти. Обговоримо задачу — і повернемося з оцінкою впровадження та планом робіт: етапи, зони відповідальності, точки перевірки.