23 lines
2.9 KiB
Markdown
23 lines
2.9 KiB
Markdown
## Основные концепции
|
||
|
||
Брокер должен быть встраиваемым в приложения на .Net. В случае встройки должна быть реализована функция подключения внешнего обработчика проходящих через брокер данных.
|
||
|
||
Брокер должен выдерживать нагрузку не хуже, чем RabbitMQ.
|
||
|
||
Брокер должен быть горизонтально масштабируемым.
|
||
|
||
## Технические особенности
|
||
|
||
1. Создается гибрид Apache Kafka и RabbitMQ. Логика организации маршрутизации сообщений будет такова:
|
||
Exchange и очереди, как в RabbitMQ, с ключами маршрутизации (Routing key). Пока планирую два вида Exchange - один отдает сообщения во все очереди с соответствующим ключем, второй - в одну, выбранную случайным образом. При этом, Exchange хранит всю прокачанную историю сообщений, как это делает Кафка.
|
||
|
||
2. Данные бэкапятся на диск в виде WAL. Скорее всего будут жить страницами минимум по 4Кб, если сообщение туда влезает. Если нет - отдельная страница для отдельного сообщения.
|
||
|
||
3. Очередь хранит в себе номер страницы WAL и id сообщения. Хочу попробовать сделать два вида очередей: классическую FIFO и стек - LIFO.
|
||
|
||
4. Инстансы будут вести несколько метрик, отражающих их проблемность. Грубо говоря что-то вроде - нормированной усреднённой по времени производной числа ошибок, потенциально вызванных инфраструктурными проблемами. Примеры событий, повышающий "рейтинг хреновости" инстанса: рестарты приложения, сетевые ошибки, ошибки при работе с диском.
|
||
|
||
5. Алгоритм выборов нового мастера внутри кластера в случае падения пока мне видится следующим:
|
||
a) При синхронной репликации выбирается наименее проблемный инстанс.
|
||
b) При асинхронной - наименее проблемный из имеющих последнюю версию данных.
|
||
Конфликты, когда все параметры кандидатов одинаковы решаются жребием:) |