Transactional Outbox - теория и практика | Паттерны Микросервисов

• В банке есть сервис "трансфер менеджер" для переводов денег.  

• Появляется новый сервис "опишн фит" для формирования истории операций пользователя.  

• Задача: отправлять данные из "трансфер менеджера" в "опишн фит".  

• Использование брокера сообщений Kafka для отправки сообщений.  

• Пользователь жалуется, что операция не отображается в списке.  

• Проблема: данные не попадают в "опишн фит" из-за перезагрузки сервера.  

• Пользователь отправил запрос на перевод денег, но сервер перезагрузился до отправки сообщения.  

• Система пришла в неконсистентное состояние, данные не согласованы.  

• Важно понимать, что маловероятные события могут произойти.  

• Нужно уметь обрабатывать маловероятные события.  

• Решение: использовать транзакции базы данных для атомарного выполнения операций.  

• Важно ознакомиться с транзакциями баз данных для предотвращения подобных проблем.  

• Современные базы данных выполняют запросы атомарно.  

• Использование распределенных транзакций для согласования изменений между базой данных и брокером очередей.  

• Алгоритм: сохранение информации о трансфере и сообщения в одну транзакцию.  

• Паттерн "транзакшн аут бокс" для атомарного выполнения операций.  

• Применение в микросервисных архитектурах для уведомления других компонентов системы.  

• В документо-ориентированных базах данных, таких как MongoDB, можно использовать отдельное поле для сообщений.  

• Отправка сообщений в Kafka не является атомарной.  

• Воркер может отправить сообщение несколько раз, если сервер перезагрузится.  

• Это называется гарантией отправки, и с этим можно жить.  

• Можно обеспечить гарантию доставки, но это сложнее.  

• Клиент должен корректно обрабатывать дубликаты сообщений.  

• Решение проблемы называется дедупликацией, где используется ключ идемпотентности.  

• Пример сервиса URL Shortener, который сокращает ссылки.  

• Уведомления о новых коротких ссылках.  

• Создание новой таблицы для хранения событий.  

• Таблица событий с полями: ID, тип события, данные, статус, время.  

• Статус используется для отслеживания обработанных сообщений.  

• Можно обойтись без поля статуса, удаляя сообщения из таблицы.  

• Использование транзакций для сохранения событий.  

• Метод saveEvent сохраняет событие в таблицу.  

• Обработка ошибок и использование пометки с названием функции.  

• Введение статусов: nil, done, reserved.  

• Использование зарезервированного статуса для предотвращения конфликтов.  

• Временный лок для резервирования сообщений.  

• Метод saveUrl сохраняет только тип события и данные.  

• Работа с базой данных в Go уже обсуждалась в других роликах.  

• Обработка ошибок и использование метода saveEvent.  

• Генерируем строку с ID, URL и эллисом.  

• Можно добавлять пользователя, сессию и другие данные.  

• Рекомендуется выносить строки в константы для упрощения.  

• Выполняем все запросы и коммитим транзакцию.  

• Если есть ошибка, откатываем транзакцию.  

• Рекомендуется использовать именованные переменные для обработки ошибок.  

• Если есть ошибка, делаем ролбек.  

• Проверяем ошибку коммита, чтобы избежать потери данных.  

• Можно подменить исходную ошибку на ошибку коммита или вернуть обе ошибки.  

• Создаем модель для ивентов с ID, типом и пайлоттом.  

• Используем промежуточную модель для получения значений из базы данных.  

• Метод для получения событий из таблицы взят из референсного проекта.  

• Обновляем статус сообщения в базе данных.  

• Используем запрос UPDATE для установки статуса.  

• Метод прост и не требует подробного обсуждения.  

• Создаем сервис для обработки ивентов.  

• Описываем структуру сервиса и используем встроенный логер.  

• Пишем функцию для запуска процесса обработки ивентов.  

• Передаем контекст и период времени для опроса таблицы.  

• Инициализируем логер и создаем переменную тикер.  

• Используем цикл для опроса таблицы с заданным периодом времени.  

• Проверка контекста на отмену или дедлайн.  

• Использование тикера для ожидания сообщений.  

• Ожидание сообщений из тикера и выполнение кода при их получении.  

• Получение событий из сторожа и обработка ошибок.  

• Использование контекста для обработки событий.  

• Обработка ошибок и запись в лог.  

• Отправка событий и обработка ошибок при отправке.  

• Использование структуры для передачи данных.  

• Проверка и отправка событий в лог.  

• Создание и запуск сервиса для отправки событий.  

• Использование временных решений для совместимости.  

• Настройка периода получения событий.  

• Использование функциональных тестов для проверки работы сервиса.  

• Проверка добавления событий в базу данных.  

• Анализ логов для подтверждения работы сервиса.  

• Подведение итогов и объяснение паттерна аут-бокс.  

• Рекомендации по использованию паттерна и ссылки на статьи.  

• Призыв к подписке на телеграм-канал для обсуждения будущих тем.