Мы используем RabbitMQ в качестве посредника, в котором мы отделяем веб-приложения OLTP, которые обрабатывают данные транзакций, от других проблем, таких как приложения для отчетов. В этой конкретной экосистеме отчетные данные должны быть как можно более актуальными, чтобы не допускать, чтобы сообщения просто пропали без вести.
Однако сообщения могут пропадать по разным причинам, и даже если встроенный издатель rabbitmq подтверждает и активирует подтверждения, у нас все еще могут отсутствовать некоторые сообщения в случае сценариев пограничного случая, например, сбои в сети.
Итак, мы нашли решение - сервис переиздания.
Служба переиздания работает следующим образом:
- Начинается каждые 30 минут по расписанию
- Для соответствующего временного окна, получает количество событий из хранилища данных источника (WebServiceA), получает количество событий из хранилища данных назначения (ReportingService), проверяет, совпадают ли они. Если они совпадают - выход
- Поскольку счетчики не совпадают, получает данные о событиях за последние 2 часа из исходной прикладной программы dababase (WebServiceA)
- Повторно публикует каждое сообщение для rabbitmq брокера
- Приложение подписки (ReportingService) является идемпотентным, то есть оно может обрабатывать получение одного и того же сообщения много раз
Решение, которое у нас есть, работает, оно не обеспечивает 100% -ную гарантию доставки, но благодаря системе безопасности службы переиздания нам еще не удалось увидеть сообщения, которые не могут попасть в пункт назначения.
Вопрос, который у меня возникает, заключается в том, делаем ли мы это неправильно или изобретаем колесо? Есть ли кто-нибудь, кто имеет аналогичные требования, и вы гарантировали доставку таким же образом?
Мы знаем, что этот подход плох с архитектурной точки зрения, поскольку переиздателю необходим прямой доступ как к исходной, так и к целевой базе данных. (общая база данных). Это также означает, что в любое время, когда нам нужно добавить отчетность для новых исходных сервисов, мы также должны написать код повторной публикации.