diff --git a/dev/architecture/highload/Балансировка нагрузки.md b/dev/architecture/highload/Балансировка нагрузки.md index 81960736..7342d458 100644 --- a/dev/architecture/highload/Балансировка нагрузки.md +++ b/dev/architecture/highload/Балансировка нагрузки.md @@ -1,6 +1,7 @@ --- aliases: - балансировку нагрузки + - Балансировщик нагрузки tags: - maturity/🌱 date: 2024-06-13 diff --git a/dev/architecture/highload/Горизонтальное масштабирование.md b/dev/architecture/highload/Горизонтальное масштабирование.md index eef0396f..ab053fa3 100644 --- a/dev/architecture/highload/Горизонтальное масштабирование.md +++ b/dev/architecture/highload/Горизонтальное масштабирование.md @@ -24,6 +24,9 @@ linked: 2. **Сложность разработки**: Разработка приложений, способных эффективно использовать ресурсы в распределенной среде, может быть более сложной, а значит программисты обходятся дороже. 3. **Согласованность данных**: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности. 4. **Затраты на сеть**: Горизонтальное масштабирование может повлечь за собой увеличенные затраты на сетевое оборудование и управление сетью, особенно если узлы географически распределены. + +Частные проблемы: +- [[../Проблема горизонтального масштабирования Websocket|Проблема горизонтального масштабирования Websocket]] *** ## Мета информация **Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]] @@ -37,4 +40,5 @@ linked: - [[garden/ru/dev/architecture/highload/Репликация.md|Репликация]] +- [[Проблема горизонтального масштабирования Websocket]] diff --git a/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md b/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md new file mode 100644 index 00000000..4af7702a --- /dev/null +++ b/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md @@ -0,0 +1,33 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2024-11-12 +--- +При реализации [[../Идемпотентность|идемпотентности]] в системах, где требуется многократная обработка событий или вызовов, [[../../../meta/zero/00 Redis|Redis]] может быть использован как ключевой инструмент для предотвращения повторной обработки сообщений. Данное решение подходит для различных систем обмена сообщениями, таких как [[../../../../../_inbox/00 Kafka|Kafka]], [[../../system-design/gRPC|gRPC]], [[../../network/HTTP|HTTP]], и других видов асинхронных или синхронных вызовов. +### Основной подход +Каждое сообщение или запрос должен иметь уникальный идентификатор, обычно называемый **requestId**. Этот идентификатор присваивается при создании сообщения или вызова и передаётся вместе с ним в процессе обработки. Потребитель, получая сообщение, сначала проверяет наличие **requestId** в Redis. Этот подход позволяет контролировать, было ли сообщение уже обработано и в каком оно состоянии. + +Алгоритм выглядит следующим образом: +1. **Получение сообщения**: Потребитель получает сообщение, извлекает **requestId** и проверяет его наличие в Redis. + 1. Если **requestId** уже существует в Redis и статус обработки указывает на **COMPLETED**, потребитель ничего не делает и отправляет **ack** (подтверждение) в Kafka (или другой источник). +2. **Обработка сообщения**: Если **requestId** отсутствует в Redis или статус обработки указывает на **FAILED**, потребитель, то потребитель обрабатывает сообщение. Перед обработкой статус в Redis обновляется на **IN_PROGRESS** с TTL, например, 40 секунд. +3. **Запись результата**: + - После успешной обработки статус в Redis обновляется на **COMPLETED**, и устанавливается длительный TTL, например, на 3-24 часа, чтобы сигнализировать, что это сообщение уже было успешно обработано и повторная обработка не требуется. + - Если при обработке возникает ошибка, статус обновляется на **FAILED** и потребитель отправляет **nack** в Kafka (или другой источник). +### Рекомендации по реализации +- **Уникальность requestId**: Генерируйте **requestId** таким образом, чтобы обеспечить его уникальность в пределах всей системы, например, используя UUID или другие подходящие алгоритмы. +- **Оптимальный TTL**: Выберите TTL в зависимости от требований к ретеншену данных. Слишком короткий TTL может привести к потере информации об обработке, а слишком длинный — к переполнению Redis. +*** +## Мета информация +**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]] +**Родитель**:: [[../Идемпотентность|Идемпотентность]] +**Источник**:: +**Создана**:: [[2024-11-12]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Идемпотентность.md b/dev/architecture/Идемпотентность.md index 68bb6ba1..b7d31456 100644 --- a/dev/architecture/Идемпотентность.md +++ b/dev/architecture/Идемпотентность.md @@ -2,19 +2,20 @@ aliases: - идемпотентны - идемпотентной + - идемпотентности tags: - maturity/🌱 date: 2024-09-11 -zero-link: - - "[[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]" -parents: -linked: --- Идемпотентность — это свойство операции, при котором многократное выполнение этой операции с одинаковыми входными данными не изменяет результат после первого выполнения. Иными словами, независимо от того, сколько раз вы выполните операцию, итог будет одним и тем же. Примером идемпотентной операции может быть запрос на установку значения, например, «установить цену товара в 100». Если отправить этот запрос несколько раз, цена останется 100, и результат не изменится. В противоположность этому, операция «увеличить цену на 10» не является идемпотентной, так как каждое выполнение увеличивает цену, и результат меняется. Идемпотентность позволяет системе быть устойчивой к ошибкам и повторам — если запрос случайно повторится, это не приведет к нежелательным изменениям. + +Примеры реализации: +- С использованием уникального идентификатора +- Логика приложения устроена таким образом, что выполнение запроса с одними и теми же параметрами всегда приводит к одному и тому же результату. *** ## Мета информация **Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]] @@ -27,3 +28,6 @@ linked: ### Дочерние заметки + +- [[Идемпотентность на базе уникального идентификатора]] + diff --git a/dev/architecture/Проблема горизонтального масштабирования Websocket.md b/dev/architecture/Проблема горизонтального масштабирования Websocket.md new file mode 100644 index 00000000..3fe04cd1 --- /dev/null +++ b/dev/architecture/Проблема горизонтального масштабирования Websocket.md @@ -0,0 +1,33 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2024-11-13 +--- +WebSocket-соединение, в отличие от [[../system-design/RESTful|REST]], имеет состояние, которое представлено объектом класса `Session`. Это создает трудности при горизонтальном масштабировании. + +Представим, что наш сервис чатов развернут в Kubernetes с 3 репликами. Пользователь чата открывает три вкладки браузера с нашим онлайн-чатом. [[highload/Балансировка нагрузки|Балансировщик нагрузки]], использующий алгоритм round robin, распределяет соединения между тремя репликами, и каждое соединение (каждая вкладка) попадает на свою реплику. + +Проблема заключается в том, что ==каждая реплика знает только о своих подключениях и не имеет информации о подключениях других реплик==. Если кто-то отправляет новое сообщение на первую реплику, пользователь увидит это сообщение только в той вкладке, которая подключена именно к этой реплике. + +Есть несколько способов решить проблему масштабирования для сервисов, использующих WebSocket. Основные варианты включают: + +1. **Не предпринимать никаких действий**. В некоторых приложениях строгая синхронизация между WebSocket-соединениями не требуется. Например, ==если ваше приложение только принимает сообщения или отправляет данные для всех пользователей, и вам не важно, из какой реплики они отправляются, возможно, нет необходимости решать эту проблему.== +2. **Использовать другой алгоритм балансировки**. Вы можете настроить балансировку так, чтобы все соединения одного и того же чата всегда направлялись на одну и ту же реплику. Это может вызвать менее равномерное распределение нагрузки, но решит проблему синхронизации между репликами. +3. [[Тонкий Websocket клиент]] +*** +## Мета информация +**Область**:: [[../../meta/zero/00 HighLoad|00 HighLoad]] +**Родитель**:: [[architecture/highload/Горизонтальное масштабирование|Горизонтальное масштабирование]] +**Источник**:: +**Создана**:: [[2024-11-13]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Тонкий Websocket клиент]] + + diff --git a/dev/architecture/Тонкий Websocket клиент.md b/dev/architecture/Тонкий Websocket клиент.md new file mode 100644 index 00000000..e519eda6 --- /dev/null +++ b/dev/architecture/Тонкий Websocket клиент.md @@ -0,0 +1,24 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2024-11-13 +--- +При таком подхода вся логика по работе с Websoket соединениями переносится в отдельный сервис. WebSocket-сервис занимается только управлением соединениями и не выполняет бизнес-логику. Вся бизнес-логика обрабатывается отдельным сервисом, который не работает с WebSocket напрямую. Когда WebSocket-сервис получает сообщение, он пересылает его в бизнес-сервис через [[брокер сообщений]], например, [[../../../../_inbox/00 Kafka|Kafka]]. + +Бизнес-сервис обрабатывает сообщение и отправляет его обратно во все реплики WebSocket-сервиса, чтобы сообщение было доставлено всем участникам чата. Для того чтобы все реплики WebSocket-сервиса получали сообщение одновременно, можно использовать [[../../../../_inbox/00 Kafka|Kafka]] [[../../../../_inbox/Consumer Group|Consumer Group]]. + +![[../../meta/files/images/Pasted image 20241113184935.png]] +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]] +**Родитель**:: [[Проблема горизонтального масштабирования Websocket]] +**Источник**:: +**Создана**:: [[2024-11-13]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/kafka/Dead Letter Queue.md b/dev/kafka/Dead Letter Queue.md new file mode 100644 index 00000000..063a58fd --- /dev/null +++ b/dev/kafka/Dead Letter Queue.md @@ -0,0 +1,33 @@ +--- +aliases: + - DLQ +tags: + - maturity/🌱 +date: 2024-11-12 +--- +**DLQ (Dead Letter Queue)** — это специальная очередь, используемая в системах обработки сообщений, таких как [[../../../../_inbox/00 Kafka|Kafka]], для хранения сообщений, которые не могут быть обработаны основным потребителем. Основное назначение DLQ — изолировать проблемные сообщения, чтобы они не блокировали остальную обработку и позволить команде разобраться с ними позже, не нарушая работы системы. + +> [!WARNING] Не лечите симптом +> Попадание событий в DLQ говорит о сбоях в работе системы, которые необходимо исправлять. Обработка DLQ делается на всякий случай и не является решением проблемы. + +Подходы по обработке DLQ сообщений: +- [[Перенос DLQ сообщений обратно в основной топик]] +- **Анализ и исправление ошибок**: Можно настроить процесс, который анализирует причины неудачной обработки и предпринимает меры по их исправлению (например, корректировка данных или обновление логики обработки). +- **Уведомления и алерты**: Настроить систему оповещений, которая уведомляет команду о наличии сообщений в DLQ, чтобы они могли вручную принять меры. +- **Отложенная повторная обработка**: Использовать механизм отложенной повторной попытки с экспоненциальной задержкой, чтобы избежать постоянного быстрого переотправления сообщений. +*** +## Мета информация +**Область**:: [[00 Kafka]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2024-11-12]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Перенос DLQ сообщений обратно в основной топик]] + + diff --git a/dev/kafka/Перенос DLQ сообщений обратно в основной топик.md b/dev/kafka/Перенос DLQ сообщений обратно в основной топик.md new file mode 100644 index 00000000..423e9fe2 --- /dev/null +++ b/dev/kafka/Перенос DLQ сообщений обратно в основной топик.md @@ -0,0 +1,26 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2024-11-12 +--- +Один из распространённых подходов к обработке сообщений из [[Dead Letter Queue|DLQ]] — это перенос их обратно в основной топик с использованием специального счётчика в заголовках сообщений для контроля количества попыток. Однако такой подход может иметь несколько недостатков: + +1. **Порядок сообщений**: Возвращение сообщений в основной топик может нарушить порядок сообщений, что критично для приложений, где последовательность имеет значение. +2. **Бесконечные циклы**: Если сообщение постоянно не удаётся обработать, оно может застрять в цикле между основным топиком и DLQ. Даже с ограничением по количеству попыток остаётся риск, что проблемные сообщения будут потреблять ресурсы без достижения результата. +3. **Нагрузка на систему**: Повторная обработка сообщений увеличивает нагрузку на систему, что может повлиять на производительность и увеличить затраты на ресурсы. +4. **Усложнение отладки**: Труднее отслеживать и отлаживать проблемы, когда сообщения постоянно перемещаются между топиками. +5. **Потенциальные дублирования**: Возникает возможность появления дублирующихся сообщений, если не гарантируется [[../architecture/Идемпотентность|идемпотентность]] при обработке. +*** +## Мета информация +**Область**:: [[00 Kafka]] +**Родитель**:: [[Dead Letter Queue|Dead Letter Queue]] +**Источник**:: +**Создана**:: [[2024-11-12]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/meta/files/images/Pasted image 20241113184935.png b/meta/files/images/Pasted image 20241113184935.png new file mode 100644 index 00000000..ef15defa Binary files /dev/null and b/meta/files/images/Pasted image 20241113184935.png differ diff --git a/meta/files/images/comp/Pasted image 20241113184935.png b/meta/files/images/comp/Pasted image 20241113184935.png new file mode 100644 index 00000000..9b502cd8 Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241113184935.png differ diff --git a/meta/files/images/comp/Pasted image 20241113184935.png.md5 b/meta/files/images/comp/Pasted image 20241113184935.png.md5 new file mode 100644 index 00000000..b5012d48 --- /dev/null +++ b/meta/files/images/comp/Pasted image 20241113184935.png.md5 @@ -0,0 +1 @@ +4caec95bad8e91abd1bda6f41abe0da0 diff --git a/meta/files/images/webp/Pasted image 20241113184935.webp b/meta/files/images/webp/Pasted image 20241113184935.webp new file mode 100644 index 00000000..fb3c113b Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241113184935.webp differ diff --git a/meta/files/images/webp/Pasted image 20241113184935.webp.md5 b/meta/files/images/webp/Pasted image 20241113184935.webp.md5 new file mode 100644 index 00000000..b5012d48 --- /dev/null +++ b/meta/files/images/webp/Pasted image 20241113184935.webp.md5 @@ -0,0 +1 @@ +4caec95bad8e91abd1bda6f41abe0da0