Что такое HTTP Header?
(продолжение предыдущего поста)

HTTP Header — это метаданные, которые сопровождают HTTP-запросы и ответы, предоставляя дополнительный контекст о коммуникации между клиентом (браузером) и сервером. Они состоят из пар «ключ-значение» и определяют типы контента, учётные данные для аутентификации, поведение кэширования и политики безопасности.

На изображении показаны два типа заголовков: HTTP Request Header (отправляется от клиента к серверу) и HTTP Response Header (отправляется от сервера к клиенту). Разберём их подробнее.

#### 1. HTTP Request Header (заголовки запроса)

Эти заголовки отправляются от клиента (браузера) к серверу и содержат информацию о запросе, возможностях клиента и ожиданиях от ответа. На изображении представлены следующие заголовки:

- Accept: image/webp — указывает типы контента, которые клиент может обработать (в данном случае — изображения в формате WebP).
- Accept-Encoding: gzip — сообщает серверу, какие алгоритмы сжатия поддерживает клиент (здесь — gzip).
- Cookie: name=maxtext — передаёт на сервер сохранённые ранее cookies, чтобы связать запрос с конкретной сессией пользователя.
- Cache-Control: max-age=604800 — задаёт время кэширования ответа (в секундах). Значение 604800 соответствует одной неделе.
- Content-Type: text/html — определяет тип контента в теле запроса (здесь — HTML-документ).
- Content-Length: 30 — указывает размер тела запроса в байтах.
- Referer: https://name.com — показывает URL страницы, с которой был отправлен запрос (помогает серверу понять источник трафика).
- User-Agent: Mozilla/5.0 — идентифицирует браузер или клиентское приложение, отправившее запрос. Сервер может адаптировать ответ под возможности клиента.

#### 2. HTTP Response Header (заголовки ответа)

Эти заголовки отправляются от сервера к клиенту и содержат метаданные об ответе, включая инструкции по обработке данных. На изображении представлены такие заголовки:

- Access-Control-Allow-Origin: \*** — определяет, какие источники (домены) могут обращаться к ресурсу. Звёздочка (*) означает, что доступ разрешён всем.
- **Alt-Svc: h2=":433"; ma=604800 — сообщает клиенту о поддержке альтернативных протоколов (например, HTTP/2 на порту 433) и сроке их действия (ma — max-age, в секундах).
- Cache-Control: max-age=604800 — аналогично запросу, задаёт время кэширования ответа на клиенте.
- Content-Type: image/webp — указывает тип контента в ответе (здесь — изображение в формате WebP).
- Content-Length: 30 — размер тела ответа в байтах.
- Date: Mon, 29 May 2023 17:15:36 GMT — дата и время создания ответа (в формате GMT).
- Set-Cookie: name=alex — сервер отправляет клиенту cookie для сохранения состояния сессии.
- Server: gws — сообщает о программном обеспечении сервера (здесь — Google Web Server, GWS).

#### Итог

- Заголовки запроса помогают серверу понять, что ожидает клиент, какие форматы данных он поддерживает и как обрабатывать запрос.
- Заголовки ответа дают клиенту инструкции по обработке данных (кэширование, тип контента, отправка cookies и т. д.) и содержат метаинформацию о сервере и ответе.

Приложения, созданные с помощью Vibe-кодирования, полны ошибок безопасности

Приложения, созданные с использованием Vibe-кодирования, когда разработчик предоставляет агенту полную свободу действий, скорее всего, будут небезопасными, а популярные агенты, такие как Claude Code, содержат элементарные логические ошибки.
Об этом заявил Ори Дэвид, исследователь из стартап-компании Tenzai, занимающейся вопросами безопасности, который создал три разных приложения, используя одни и те же подробные подсказки с пятью агентами кодирования, используя их стандартные LLM. Исследователь обнаружил примерно одинаковое количество уязвимостей в каждой реализации,


Согласно исследованию, агенты хорошо себя вели в отношении некоторых известных классов ошибок, таких как SQL-инъекции и межсайтовый скриптинг, но плохо справлялись с логикой авторизации и бизнес-логикой.
Примером последнего является то, что большинство агентов позволяли пользователям заказывать отрицательное количество товаров в приложении электронной коммерции и отрицательные цены при создании товаров продавцами.

Среди других распространенных недостатков — уязвимость к подделке запросов на стороне сервера (SSRF) и отсутствие лучших практик в области безопасности, таких как заголовки безопасности.

Агенты программирования не гарантируют безопасность сгенерированного кода, и тот факт, что приложения, созданные с помощью vibe-кодирования, имеют уязвимости в безопасности, не является ни удивительным, ни недостатком самих агентов. Проблема в том, что vibe-кодирование позволяет разрабатывать приложения неквалифицированным разработчикам или тем, кто обладает навыками работы с подсказками ИИ, а не навыками программирования. Если эти простые приложения содержат существенные недостатки, более сложные проекты, вероятно, будут еще менее безопасными.

https://devclass.com/2026/01/15/vibe-coded-applications-full-of-security-blunders/

Авторы Ubuntu протестировали ИИ на своей документации. Главный вывод оказался неожиданным: сэкономленное время съедается проверкой результатов.

Тестировались Claude Sonnet 4.5, Claude Haiku 4.5, GPT-5, GPT-5-mini и Gemini 3 Pro. Первая задача — перевести документацию с британского английского на американский. Claude Sonnet справился на 7 из 10, GPT-5 получил ноль баллов — просто отказался выполнять задачу без объяснения причин. Gemini работал медленно, а потом начал менять слова в обратную сторону. Когда автор указала на ошибку, модель сначала согласилась, затем "поговорила сама с собой" и заявила, что жалоба "необоснована".

На других задачах ИИ показал себя лучше. Claude написал метаописания для 250 страниц, сэкономив команде одну-две недели работы. Оптимизация линкчекера сократила время проверки с 10 минут до полутора — на 85%. Рабочий скрипт для автообновления редиректов тоже получился с первой попытки.

Но в итоге оказалось, что ревью работы ИИ-агентов занимает в два-три раза больше времени, чем ревью работы коллег-людей. Иногда модели делают "случайные и неожиданные вещи" — и чем лучше они справляются в целом, тем выше риск пропустить ошибку.

https://discourse.ubuntu.com/t/ubuntu-server-gazette-issue-11-ai-bots-shall-eat-my-docs/75029

Уровни дизайна системы
(продолжение в следующем посте)

Уровни дизайна системы
(продолжение предыдущего поста)

1. Level 0: Основы
На этом базовом уровне закладываются фундаментальные элементы системы:
* HTTP Methods (Методы HTTP) — основа взаимодействия между клиентом и сервером (GET, POST, PUT, DELETE и др.).
* REST APIs (REST API) — стандартизированный способ построения API для обмена данными.
* Basic Database Operations (Базовые операции с БД) — работа с базами данных (создание, чтение, обновление, удаление данных — CRUD-операции).

Этот уровень формирует «скелет» системы, без которого невозможно дальнейшее развитие архитектуры.

2. Level 1: Освоение базовых блоков
Здесь система усложняется за счёт внедрения инфраструктурных компонентов:
* Load Balancers (Балансировщики нагрузки) — распределяют нагрузку между серверами для повышения производительности и надёжности.
* Caching Strategies (Стратегии кэширования) — ускоряют доступ к данным за счёт временного хранения результатов запросов (например, Redis, Memcached).
* Message Queues (Очереди сообщений) — обеспечивают асинхронную обработку задач (например, RabbitMQ, Kafka), снижают нагрузку на систему и повышают её устойчивость.

Эти компоненты позволяют системе эффективно работать под нагрузкой и справляться с пиками запросов.

3. Level 2: Взаимосвязанные компоненты
На этом уровне система проектируется с учётом сложных сценариев:
* API (API-интерфейсы) — формализуют взаимодействие между компонентами системы.
* CQRS (Command Query Responsibility Segregation) — разделяет команды (изменение данных) и запросы (чтение данных), что упрощает архитектуру и повышает производительность.
* Use circuit breakers, retries and timeouts (Использование схем прерывания, повторных попыток и таймаутов) — защищает систему от каскадных сбоев: если один сервис недоступен, система не падает, а обрабатывает ошибку.
* Add rate limiting and backpressure (Ограничение скорости и обратная связь по нагрузке) — предотвращает перегрузку системы за счёт контроля числа запросов.
* Design idempotent endpoints (Проектирование идемпотентных конечных точек) — гарантирует, что повторные идентичные запросы не изменят состояние системы.
* Separate read and write paths (Разделение путей чтения и записи) — оптимизирует работу с данными: чтение выполняется быстрее, запись — надёжнее.

Этот уровень делает систему устойчивой к ошибкам и способной работать в сложных условиях.

4. Level 3: Надёжность и мониторинг
Здесь акцент делается на мониторинге и диагностике:
* Monitoring (Мониторинг) — сбор метрик (время отклика, загрузка ЦП, память) для отслеживания состояния системы.
* Logging (Логирование) — запись событий и ошибок для последующего анализа.
* Alerting Systems (Системы оповещения) — автоматическое уведомление о критических событиях (сбои, превышение лимитов).

Эти инструменты позволяют оперативно реагировать на проблемы и поддерживать стабильную работу системы.

5. Level 4: Масштабирование и развитие
Финальный уровень посвящён масштабируемости и гибкости:
* Scalability (Масштабируемость) — способность системы справляться с ростом нагрузки (горизонтальное и вертикальное масштабирование).
* High Availability (Высокая доступность) — минимизация простоев за счёт резервирования компонентов (например, кластеризация баз данных).
* Distributed Systems (Распределённые системы) — разделение системы на независимые узлы, работающие совместно (например, микросервисы).
* Microservices (Микросервисы) — разбиение монолита на небольшие независимые сервисы, упрощающие разработку и развёртывание.
* Event Driven Architecture (Архитектура, управляемая событиями) — система реагирует на события (например, сообщения в очереди), что повышает её гибкость.
* Handle partial failures in distributed systems (Обработка частичных сбоев в распределённых системах) — система продолжает работать, даже если некоторые узлы недоступны (например, с помощью паттернов retry, circuit breaker).

Этот уровень обеспечивает долгосрочную жизнеспособность системы, её способность адаптироваться к изменениям и расти вместе с бизнесом.

Таким образом, уровни дизайна системы выстраиваются от базовых принципов (Level 0) до сложной архитектуры, способной масштабироваться и эволюционировать (Level 4). Каждый уровень дополняет предыдущий, формируя надёжную, производительную и гибкую систему.

СМИ: Роскомнадзор ввел новые ограничения против Telegram

Роскомнадзор ввел новые ограничения в отношении мессенджера Telegram. Об этом сообщает телеканал «Москва 24» со ссылкой на источник на телеком-рынке.

В СМИ отметили, что пользователи активно жалуются на медленную загрузку видео. По информации источника, «это новые ограничения со стороны РКН».

Тем временем Роскомнадзор опроверг блокировку Telegram в России. «По отношению к Telegram в настоящее время новых мер ограничений не применяется», – сообщили в ведомстве.

https://t.me/infomoscow24/104004

Когда оперативка бесконечная

Жизненный цикл образа Docker
(продолжение в следующем посте)

Жизненный цикл образа Docker
(продолжение предыдущего поста)

Жизненный цикл образа Docker включает несколько ключевых этапов, которые отображены на схеме:

1. Создание Dockerfile
Разработчику необходимо создать файл конфигурации Dockerfile, в котором задаются инструкции для настройки окружения приложения. В Dockerfile указываются базовый образ (директива FROM), рабочая директория (WORKDIR), копирование файлов (COPY), выполнение команд (RUN) и другие настройки.

2. Сборка образа (Build process)
С помощью команды docker build -t my-node-app . запускается процесс сборки образа на основе Dockerfile. Docker последовательно применяет инструкции из файла, формируя слои образа. Параметр -t задаёт тег (имя) для образа — в данном случае my-node-app.

3. Теггирование образа (Tagging)
После сборки образу присваивается тег (уникальное имя), например, my-node-app. Теггирование упрощает дальнейшую работу с образом — его легче идентифицировать и использовать.

4. Хранение образа локально
Собранный образ сохраняется на локальной машине пользователя. Список локальных образов можно вывести с помощью команды docker images.

5. Удаление локального образа (при необходимости)
Если образ больше не нужен, его можно удалить с помощью команды docker rmi my-node-app. Это освобождает место на диске.

6. Аутентификация для работы с Docker Hub
Чтобы загрузить образ в публичный реестр Docker Hub, требуется аутентификация. Выполняется команда docker login, где пользователь вводит свои учётные данные Docker Hub.

7. Перетегирование для Docker Hub
Перед загрузкой в Docker Hub образ необходимо перетеггировать, добавив имя пользователя:
docker tag my-node-app username/my-node-app.
Здесь username — это логин пользователя в Docker Hub. Это обязательное условие для публикации образа.

8. Загрузка образа в Docker Hub (Push)
Выполняется команда docker push username/my-node-app, которая отправляет образ в публичный реестр Docker Hub. После этого образ становится доступным для скачивания другим пользователям.

9. Скачивание образа (Pull)
Любой пользователь может скачать опубликованный образ с Docker Hub с помощью команды docker pull username/my-node-app. Скачанный образ сохраняется локально на машине пользователя.

10. Использование образа для создания контейнеров
После скачивания образ используется для запуска контейнеров — изолированных экземпляров приложения. Контейнеры работают на основе образа и могут быть запущены с помощью команды docker run.

Таким образом, жизненный цикл Docker-образа включает создание конфигурации (Dockerfile), сборку и теггирование локального образа, его загрузку в публичный реестр (Docker Hub) и последующее скачивание и использование другими пользователями для развёртывания приложений. Каждый этап управляется специальными командами Docker CLI и обеспечивает гибкость и безопасность при работе с образами.

SSD стали дороже золота, если сравнивать цену за грамм

Портал Tom’s Hardware проанализировал рынок SSD и пришёл к выводу, что твердотельные накопители SSD большой ёмкости стали дороже золота, если сравнивать цену за грамм. Это утверждение верно для NVMe-накопителей на 8 ТБ, также к этому показателю стремительно приближаются модели с 4 ТБ. Ситуация связана с дефицитом металлов на рынке ОЗУ и SSD из-за высокого спроса со стороны компаний в сфере искусственного интеллекта.

Tom’s Hardware использовал цены на SSD в Newegg, Microcenter, Best Buy и Walmart, получив более ста вариантов. Требования были такими: NVMe SSD с интерфейсом PCIe 4.0 или 5.0 ёмкостью 4 ТБ, продаваемые магазином и имеющиеся в наличии. В анализ не стали включать накопители корпоративного класса.

Оценка среднего веса этого сегмента SSD даёт в среднем 8,2 г для моделей на 8 ТБ или 8 г в случае вариантов на 4 ТБ. Рассматривались только версии без радиаторов.
В настоящее время золото стоит $148 за грамм. Даже если брать нижний предел веса накопителя в 8 г, средняя стоимость золота составит около $1148. В то же время средняя цена потребительского накопителя на 8 ТБ достигает примерно $1476, а высокопроизводительная модель будет стоить значительно больше.

Стоимость некоторых моделей накопителей ёмкостью 4 ТБ также приближается к эквивалентной цене золота. Существует явный разрыв между более дорогими моделями. За некоторым исключением, большая часть сегмента до $800 приходится на SSD для хранения данных. Это означает, что если пользователю нужна и высокая производительность, то придётся заплатить больше.

https://www.tomshardware.com/pc-components/storage/high-capacity-nvme-ssds-are-quickly-becoming-as-expensive-as-gold-by-weight-we-ran-the-figures-heres-what-we-found

Сравнение цены золота и SSD наглядно на графике

Как работает CDN
(продолжение в следующем посте)

Как работает CDN
(продолжение предыдущего поста)

Сеть доставки контента (CDN) — это географически распределённые серверы (также называемые пограничными серверами - edge servers), которые обеспечивают быструю доставку статического и динамического контента. Давайте разберём, как это работает.

Предположим, Боб, который живёт в Нью‑Йорке, хочет зайти на сайт электронной коммерции, размещённый в Лондоне. Если запрос отправится на серверы, расположенные в Лондоне, ответ будет довольно медленным. Поэтому мы размещаем CDN‑серверы поближе к тому месту, где живёт Боб, — и контент будет загружаться с ближайшего CDN‑сервера.

Приведённая выше схема иллюстрирует этот процесс:

1. Боб вводит в браузере www.myshop.com. Браузер ищет доменное имя в локальном кэше DNS.

2. Если доменное имя отсутствует в локальном кэше DNS, браузер обращается к DNS‑резолверу для разрешения имени. DNS‑резолвер обычно находится у провайдера интернет‑услуг (ISP).

3. DNS‑резолвер рекурсивно разрешает доменное имя (подробности см. в моём предыдущем посте). В конце концов он обращается к авторитетному серверу имён для разрешения доменного имени.

4. Если мы не используем CDN, авторитетный сервер имён возвращает IP‑адрес для www.myshop.com. Но при использовании CDN у авторитетного сервера имён есть псевдоним, указывающий на www.myshop.cdn.com (доменное имя CDN‑сервера).

5. DNS‑резолвер запрашивает у авторитетного сервера имён разрешение для www.myshop.cdn.com.

6. Авторитетный сервер имён возвращает доменное имя для балансировщика нагрузки CDN — www.myshop.lb.com.

7. DNS‑резолвер обращается к балансировщику нагрузки CDN для разрешения www.myshop.lb.com. Балансировщик выбирает оптимальный пограничный CDN‑сервер на основе IP‑адреса пользователя, провайдера пользователя, запрашиваемого контента и нагрузки на сервер.

8. Балансировщик нагрузки CDN возвращает IP‑адрес пограничного CDN‑сервера для www.myshop.lb.com.

9. Теперь мы наконец получаем фактический IP‑адрес, к которому нужно обратиться. DNS‑резолвер передаёт IP‑адрес браузеру.

10. Браузер обращается к пограничному CDN‑серверу (edge server) для загрузки контента.

На CDN‑серверах кэшируются два типа контента: статический и динамический. Первый включает статические страницы, изображения, видео; второй — результаты краевых вычислений.

Если в кэше пограничного CDN‑сервера (edge CDN server) нет нужного контента, запрос направляется на региональный CDN‑сервер. Если контент по‑прежнему не найден, запрос идёт на центральный CDN‑сервер или даже на исходный сервер — веб‑сервер в Лондоне. Это называется CDN‑распределительной сетью, где серверы развёрнуты с учётом географического расположения.

Советы по работе с PATH
(продолжение в следующем посте)

Советы по работе с PATH
(продолжение предыдущего поста)

Следующие советы помогут эффективно управлять PATH и решать распространённые проблемы, связанные с поиском и запуском программ в терминале.

1. Добавление директории в PATH:
* В конце PATH (чтобы приоритет был у уже существующих путей):

     export PATH=$PATH:/my/dir
     

* В начале PATH (чтобы добавленная директория имела приоритет):

     export PATH=/my/dir:$PATH
     

* Для оболочки fish:

     set PATH $PATH /my/dir
     

2. Настройка PATH в конфигурационных файлах оболочки:
* Для bash: отредактируйте файлы ~/.bashrc или ~/.bash_profile.
* Для zsh: используйте файл ~/.zshrc.
* Для fish: настройте в файле ~/.config/fish/config.fish.

3. Просмотр текущего PATH:
* Чтобы увидеть содержимое PATH в одной строке:

     echo $PATH
     

* Чтобы вывести каждую запись PATH на отдельной строке (для bash/zsh):

     echo $PATH | tr ':' '\n'
     

4. Поиск программ в PATH:
* Показать первую директорию, где найдена программа (например, python3):

     which python3
     

(в zsh команда which работает как type).
* Показать все директории, где найдена программа (в порядке приоритета):

     which -a python3
     

5. Узнать, какая именно версия программы будет запущена:
* Используйте команду type, чтобы увидеть, что именно запустится при вызове программы (включая алиасы, встроенные команды и кэшированные записи):

     type python3
     

6. Очистка кэша PATH (для bash/zsh):
* Иногда обновление PATH не работает из-за кэширования. Очистите кэш с помощью команды:

     hash -r
     

* Это необходимо, если после добавления директории в PATH команды не работают корректно.

7. Важные нюансы:
* Bash и zsh кэшируют результаты поиска программ в PATH. Если вы добавили новую директорию, но команды не работают — очистите кэш (hash -r).
* Порядок добавления директорий в PATH влияет на приоритет поиска программ.
* Убедитесь, что изменения в конфигурационных файлах применяются (перезапустите терминал или выполните source ~/.bashrc / source ~/.zshrc / source ~/.config/fish/config.fish).

Вышла jQuery 4.0

Возможно, звучит как шутка, но вышла новая версия популярной JS-библиотеки jQuery - 4.0. Напомню, что версия 3.0 вышла почти 10 лет назад.

По данным организации W3Techs эту библиотеку используют на 70.9% из 10 млн наиболее посещаемых сайтов в сети.

Выпуск jQuery 4.0 содержит изменения, нарушающие обратную совместимость и связанные с удалением устаревшего кода, удалением некоторых внутренних недокументированных параметров, прекращением поддержки некоторого излишне усложнённого поведения и прекращением поддержки API, ранее объявленных устаревшими.
Для упрощения миграции можно использовать специальный плагин.

Причем удаление поддержки устаревших API и браузеров позволило сократить размер gzip-архива с библиотекой на 3 КБ (slim-версия теперь занимает 19.5 КБ, а полная - 27.5 КБ).

Среди основных изменений:

- Прекращена поддержка браузера IE 10 и более старых версий (поддержка IE 11 сохранена, но будет удалена в jQuery 5.0), а также других старых браузеров таких как Edge Legacy, Android Browser и Firefox до ветки 115.

- Встроена поддержка API Trusted Types, развиваемого для защиты от манипуляций с DOM, приводящих к межсайтовому скриптингу (DOM XSS), например, при некорректной обработке полученных от пользователя данных в блоках eval() или вставках ".innerHTML", что может привести к выполнению JavaScript-кода в контексте определённой страницы. В методы jQuery теперь может передаваться HTML-код в форме объектов TrustedHTML.

- jQuery теперь использует модули ESM (ECMAScript Module), соответственно код библиотеки может поставляться и импортироваться как модуль

- Удалены устаревшие функции: jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.nodeName, jQuery.cssNumber, jQuery.cssProps и jQuery.fx.interval.
Вместо данных функций рекомендуется использовать штатные JavaScript-функции Array.isArray(), JSON.parse(), String.prototype.trim() и Date.now()

- Размер урезанного варианта (slim), не содержащий модули ajax и effects, сокращён до 19.5k за счёт прекращения поставки объектов Deferred (рекомендуется использовать штатные Promises) и Callbacks.

https://blog.jquery.com/2026/01/17/jquery-4-0-0/

Добавлены материалы по библиотеке Pandas и анализу данных на языке Python
https://metanit.com/python/pandas/
#python #pandas

РКН планирует использовать ИИ для блокировки VPN и интернет-трафика, на проект заложено 2,3 млрд рублей

По информации СМИ, Роскомнадзор планирует за 2,3 млрд рублей создать систему на базе искусственного интеллекта для блокировки VPN и интернет‑трафика. Согласно плану цифровизации РКН, новая система должна начать работать уже в этом году. Алгоритм на базе ИИ будет отслеживать «зеркала» заблокированных сайтов не по IP‑адресам, а через анализ слов, фраз и предложений. Это позволит блокировать не только сайты, но и тех, кто цитирует или копирует запрещённые ресурсы. Кроме того, ИИ будет способен отслеживать зашифрованный трафик через VPN, а также замедлять доступ к конкретным ресурсам и торрент‑трекерам.

Новый механизм будет работать на базе уже действующих в сетях операторов технических средств противодействия угрозам (ТСПУ), которые обеспечивают фильтрацию по технологии DPI (Deep Packet Inspection, глубокая фильтрация трафика по содержимому пакетов). С их помощью уже заблокировано более 1 млн ресурсов, а также ежедневно ограничивается доступ к 5,5 тыс. новых адресов.

Как отмечают эксперты, опрошенные СМИ, машинное обучение может повысить эффективность блокировок и помочь в выявлении запрещенного контента и VPN‑сервисов. Кроме того, внедрение систем на основе ИИ также соответствует требованию для федеральных ведомств отчитываться по подобным проектам.

https://www.forbes.ru/tekhnologii/553640-algoritmiceskie-upraznenia-rkn-budet-fil-trovat-trafik-s-pomos-u-masinnogo-obucenia

Как работает Single-Leader Replication (Репликация с одним лидером)
(продолжение в следующем посте)

Как работает Single-Leader Replication (Репликация с одним лидером)
(продолжение предыдущего поста)

По мере роста нагрузки на приложение на первый лан выходят такие характеристики как отказоустойчивость и надежность. И одним из способов повышения отказоустойчивости и надежности является "Репликация с одним лидером" или Single-Leader Replication. Рассмотрим, как она работает.

1. Назначение ролей узлов

В системе Single-Leader Replication:
* Один узел назначается лидером (leader) — он отвечает за обработку всех операций записи (DML-запросов: INSERT, UPDATE, DELETE).
* Остальные узлы называются последователями (followers) — они реплицируют изменения, сделанные лидером, и могут отвечать на запросы чтения.

2. Обработка операций записи (write operations)

* Все операции записи направляются исключительно на лидер.
* Лидер записывает изменения в своё локальное хранилище.
* Затем лидер распространяет изменения на все последователи — это может происходить асинхронно или синхронно:
* Асинхронная репликация: лидер сразу подтверждает успешную запись, а затем отправляет изменения последователям. Быстрее, но есть риск потери данных, если лидер выйдет из строя до отправки изменений.
* Синхронная репликация: лидер ждёт подтверждения от всех последователей, что они записали изменения, прежде чем подтвердить успешную запись. Надежнее, но медленнее.
* Также существует полусинхронная репликация, когда лидер ждёт подтверждения от заданного количества последователей.

3. Обработка операций чтения (read operations)

* Запросы на чтение могут направляться как к лидеру, так и к последователям:
* Чтение с лидера: обеспечивает строгую согласованность (strong consistency) — клиент всегда получает самые актуальные данные.
* Чтение с последователей: может привести к окончательной согласованности (eventual consistency) — данные могут быть немного устаревшими, пока последователи не обновятся. Задержка репликации может составлять от нескольких секунд до нескольких минут.

4. Отказоустойчивость (failover)

* Если лидер выходит из строя, один из последователей автоматически становится новым лидером.
* Клиенты перенастраиваются для отправки записей новому лидеру.
* Остальные последователи начинают получать изменения данных от нового лидера.
* При этом возможны проблемы:
* Если использовалась асинхронная репликация, новый лидер может не получить все записи от старого лидера.
* Возможен сценарий «split brain» (расщеплённый мозг), когда старый лидер возвращается в сеть и считает себя действующим лидером.

5. Распределение нагрузки

* Добавление новых последователей помогает распределить нагрузку на чтение — больше узлов могут отвечать на запросы чтения.
* Однако пропускная способность записи (write throughput) не увеличивается, так как все операции записи по-прежнему проходят через одного лидера.

6. Репликация изменений

* Последователи получают журнал изменений (log) от лидера и применяют их к своей локальной копии базы данных.
* Если последователь выходит из строя, он может восстановиться, запросив у лидера все изменения, произошедшие с момента последней транзакции.

7. Итоги

Single-Leader Replication обеспечивает:
* Централизованную обработку записей через одного лидера.
* Распределение нагрузки чтения между последователями.
* Отказоустойчивость за счёт автоматического повышения последователя до лидера при сбое.
* Гибкость в выборе стратегии репликации (асинхронная, синхронная, полусинхронная) в зависимости от требований к скорости и надёжности.