Comments 13
@bibendi нужно отметить один важный момент - это производительность, БД становится узким местом при таком подходе. Думаю стоит про это упомянуть. И да, понятно, что мы платим эту цену за надёжность и непротиворечивость доставки.
Да, полностью согласен. Мы с этим столкнулись, хотя, к сожалению, я об этом не написал. Гем поддерживает полинг из реплики БД, что снимает значительную часть проблем, хотя может привнести новые, такие как лаг репликации.
На мой взгляд тут 2 варианта.
Горизонтально масштабируемые транзакционные бд, которых к сожалению не так много.
Шардирование имеющихся бд. Скорее всего наиболее часто используемый вариант на данный момент. Но тут конечно минус, вся кодовая база должна поддерживать шардирование.
Последние дни изучал как что Ruby в текущем году, заодно проверил количество вакансий на Rails на HH. Выглядит грустновато. А суть вопроса в том - имеет ли смысл смотреть в сторону Ruby и рельс в частности спустя 15 лет в JS/TS, из которых 8 в NodeJS? Не совсем с нуля - когда-то в 2017 целиком прочел Путь Ruby в бумажной версии на 1000 страниц и потом ещё парочку торговых роботов и аналитики на чистом Ruby без рельс было. И Ruby это кайфово. Но нужно ли оно миру или это будет лишь выбор сердца, но с деградацией по грейдам и финансам? На сколько это безумно?
Надеюсь не очень оффтоп, но не каждый день на хабре про Ruby пишут и чтобы в топ дня попало.
Не очень понятно, а на кой черт в этой схеме kafka? Если я правильно понял, у вас две таблицы в базе - outbox и inbox. Что мешает напрямую брать бэкэнд-воркеру сообщения из той же базы? Прямо из оутбокс, и помечать их статусом, что они "в обработке" Другие воркеры их уже не возьмут. По итогу тот, который взял, либо успешно завершит их обработку, либо поставит статус "ошибка", "повтор" или любой какой вам нужен. Скорость выше - т к таблица одна, транзакции короткие - только смена статусов. Надёжность та же - и у вас, и без Кафки всё упирается в то, есть ли коннект к базе (или у вас база на той же роде где и приложение?)
Ну допустим, по какой-то неведомой мне причине, воркеру база приложения недоступна. Но тогда можно, как уже подсказали, читать из wal-log или реплики... По сути в статье описан древний как мир подход "очередь через таблицу". Это работает и даже из коробки это есть, как верно вы написали, в редис. Спрашивается, а кафка зачем?
Большое спасибо Вам за статью! Вы, кстати, вдохновили меня опубликоваться на Хабре со своей реализацией, правда, на Python. Если честно, я бы хотел сопоставить решения. Вероятно, из обсуждения каждый из нас может вынести что-то полезное для своего стека.
В Вашей архитектуре есть разделение:
Важно отметить, что в нашей архитектуре получение (потребление) сообщений концептуально отделено от их фактической обработки.
Можете объяснить, почему их пришлось разделять?
Такова концепция inbox паттерна. Kafka-consumer читает из топика сообщения, складывает их в инбокс-таблицу. Inbox-демон полит сообщения из таблицы и запускает бизнес-логику их обработки
Скажите пожалуйста, рассматривали ли вы вариант, когда Kafka не фиксирует смещение (commit offset) сразу при получении сообщения из топика, а делает это после обработки?
Ведь тогда можно объединить консюмера и Inbox-демона. К тому же, Kafka самостоятельно разделяет работу между консюмерами. Этот момент теряется, если складывать все в инбокс-таблицу, а потом запускать воркеров. Что думаете?
Буду благодарен, если ознакомитесь с моей публикацией:
Это решение ещё не было в продакшне. Там разделения нет, а меня терзает мысль, что я упускаю что-то важное. Будет здорово, если разбирающийся человек укажет мне на неочевидные недочёты.
Со статьей ознакомлюсь на этой неделе.
Основные моменты почему мы использовали такую схему такие:
- демон не зависит от транспорта (Кафка), и может принимать события, которые были созданы по http
- мы не хотим завязываться на кол-во партиций в топике, чтобы делать масштабирование, в нашей схеме оно происходит независимо друг от друга
Transactional Outbox: от идеи до open-source