(продолжение предыдущего поста)
#### 1. Балансировка нагрузки (Load Balancing)
Суть: распределение входящих запросов между несколькими экземплярами серверов.
Как работает:
* клиентский запрос поступает на load balancer (балансировщик нагрузки);
* load balancer перенаправляет запрос на один из доступных серверов;
* нагрузка равномерно распределяется между серверами, что предотвращает перегрузку отдельных узлов.
Преимущества:
* повышение производительности и скорости обработки запросов;
* снижение риска отказа системы из-за перегрузки одного сервера;
* возможность горизонтального масштабирования (добавления новых серверов).
#### 2. Переключение на резервный узел (Failover)
Суть: автоматический переход на резервный сервер или компонент в случае отказа основного.
Как работает:
* система постоянно мониторит состояние основного сервера;
* при сбое основного сервера запускается механизм failover decision (решение о переключении);
* данные реплицируются (копируются) на резервный сервер;
* трафик перенаправляется на резервный сервер, который берёт на себя работу основного.
Преимущества:
* минимизация времени простоя системы;
* обеспечение непрерывности работы критически важных сервисов;
* защита от аппаратных и программных сбоев.
#### 3. Синхронная и асинхронная репликация (Synchronous vs Asynchronous Replication)
Репликация — это процесс копирования данных между основным (leader) и резервными (follower) серверами.
Синхронная репликация (Synchronous Replication):
* данные копируются на резервные серверы одновременно с их записью на основной сервер;
* гарантирует целостность данных, так как все узлы имеют одинаковую копию;
* недостаток: замедление работы системы, так как ожидание подтверждения от всех узлов может увеличить время отклика.
Пример работы:
1. Установка ключа:
set key = "foo".2. Изменение данных.
3. Подтверждение успеха на основном сервере.
5. Подтверждение успеха на резервном сервере.
Асинхронная репликация (Asynchronous Replication):
* данные копируются на резервные серверы после их записи на основной сервер;
* обеспечивает более высокую производительность, так как не ждёт подтверждения от резервных узлов;
* риск: при сбое основного сервера часть данных может быть потеряна, так как они не успели скопироваться на резервные узлы.
Пример работы:
1. Изменение данных на основном сервере.
2. Немедленное подтверждение успеха на основном сервере.
3. Отложенная репликация данных на резервные серверы.
4. Подтверждение успеха на резервном сервере.
#### 4. Обеспечение уровня доступности (Availability Numbers)
Уровень доступности измеряется в процентах и определяет максимально допустимое время простоя системы в год.
Таблица уровней доступности:
- 99% («Two nines») (Время простоя в год - 3.65 дня): Допустимо для некритичных систем
- 99.9% («Three nines») (Время простоя в год - 8.76 часов): Подходит для большинства бизнес-приложений
- 99.99% («Four nines») (Время простоя в год - 52.56 минуты): Требование для критически важных сервисов
- 99.999% («Five nines») (Время простоя в год - 5.26 минут): Высокий стандарт для финансовых и телекоммуникационных систем
- 99.9999% («Six nines») (Время простоя в год - 31.5 секунды): Максимальный уровень доступности, используется в системах жизнеобеспечения
Комбинация балансировки нагрузки, механизма failover, подходящей стратегии репликации и достижения необходимого уровня доступности позволяет построить надёжную и отказоустойчивую систему, способную выдерживать сбои и обеспечивать непрерывную работу сервисов.
