From c775125e20c330b2cea2fa0410975c1dcb7e13fd Mon Sep 17 00:00:00 2001 From: vladzvx Date: Wed, 3 Apr 2024 00:38:27 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=B8=D1=82?= =?UTF-8?q?=D1=8C=20doc/Common/Concepts.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/Common/Concepts.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/Common/Concepts.md b/doc/Common/Concepts.md index 109627a..ecac028 100644 --- a/doc/Common/Concepts.md +++ b/doc/Common/Concepts.md @@ -1,15 +1,15 @@ -Основные концепции - -1.  Создаю гибрид Apache Kafka и RabbitMQ. Логика организации маршрутизации сообщений будет такова: -Exchange и очереди, как в RabbitMQ, с ключами маршрутизации (Routing key). Пока планирую два вида Exchange - один отдает сообщения во все очереди с соответствующим ключем, второй - в одну, выбранную случайным образом. При этом, Exchange хранит всю прокачанную историю сообщений, как это делает Кафка. - -2. Данные бэкапятся на диск в виде WAL. Скорее всего будут жить страницами минимум по 4Кб, если сообщение туда влезает. Если нет - отдельная страница для отдельного сообщения. - -3. Очередь хранит в себе номер страницы WAL и id сообщения. Хочу попробовать сделать два вида очередей: классическую FIFO и стек - LIFO. - -4. Инстансы будут вести несколько метрик, отражающих их проблемность. Грубо говоря что-то вроде - нормированной усреднённой по времени производной числа ошибок, потенциально вызванных инфраструктурными проблемами. Примеры событий, повышающий "рейтинг хреновости" инстанса: рестарты приложения, сетевые ошибки, ошибки при работе с диском. - -5. Алгоритм выборов нового мастера внутри кластера в случае падения пока мне видится следующим: -a) При синхронной репликации выбирается наименее проблемный инстанс. -b) При асинхронной - наименее проблемный из имеющих последнюю версию данных. +## Основные концепции + +1. Создается гибрид Apache Kafka и RabbitMQ. Логика организации маршрутизации сообщений будет такова: +Exchange и очереди, как в RabbitMQ, с ключами маршрутизации (Routing key). Пока планирую два вида Exchange - один отдает сообщения во все очереди с соответствующим ключем, второй - в одну, выбранную случайным образом. При этом, Exchange хранит всю прокачанную историю сообщений, как это делает Кафка. + +2. Данные бэкапятся на диск в виде WAL. Скорее всего будут жить страницами минимум по 4Кб, если сообщение туда влезает. Если нет - отдельная страница для отдельного сообщения. + +3. Очередь хранит в себе номер страницы WAL и id сообщения. Хочу попробовать сделать два вида очередей: классическую FIFO и стек - LIFO. + +4. Инстансы будут вести несколько метрик, отражающих их проблемность. Грубо говоря что-то вроде - нормированной усреднённой по времени производной числа ошибок, потенциально вызванных инфраструктурными проблемами. Примеры событий, повышающий "рейтинг хреновости" инстанса: рестарты приложения, сетевые ошибки, ошибки при работе с диском. + +5. Алгоритм выборов нового мастера внутри кластера в случае падения пока мне видится следующим: +a) При синхронной репликации выбирается наименее проблемный инстанс. +b) При асинхронной - наименее проблемный из имеющих последнюю версию данных. Конфликты, когда все параметры кандидатов одинаковы решаются жребием:) \ No newline at end of file