Алгоритмы консенсуса Paxos, Raft и Zab в распределённых системах

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos , Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

https://habr.com/ru/articles/903792/

#paxos #raft #микросервисы #sql #nosql #распределенные_системы #высоконагруженные_проекты #высоконагруженные_приложения #высокая_доступность #высокая_нагрузка

И снова USB-IP — сервер теперь с автобиндом и детачем и сам подхватит ключ клиент

HA - как много в этом слове: Автоматический перенос виртуальных машин в кластере. 8 секунд и, например, сервер терминалов сменил место жительства совместно со всеми своими предустановленными программами - в другую серверную. И ... оставил аппаратные лицензии и ЭЦП, заботливыми руками проброшенные в виртуалки, тоскливо торчать из, возможно, погибшего железа. Отставить "оставил"!

https://habr.com/ru/articles/901988/

#usbip #linux #alt_linux #debian #systemd #bashscripting #распределенные_системы

Настройка Apache Kafka для высоконагруженных систем

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени. Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

https://habr.com/ru/articles/901200/

#apache_kafka #nosql #распределенные_системы #высоконагруженные_проекты #высокая_производительность #highload #высокая_нагрузка #высоконагруженные_приложения #высокая_доступность

Теорема CAP: почему нельзя иметь все сразу и как аналитик выбирает чем пожертвовать

Распределенные системы лежат в основе большинства современных приложений - от облачных сервисов до финансовых платформ и социальных сетей. Проектирование сопряжено с рядом сложных компромиссов, особенно когда речь идет о согласованности данных, доступности системы и устойчивости к сетевым сбоям. Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства. Это ограничение имеет ключевое значение для системных аналитиков и архитекторов, которым необходимо принимать решения о том, какие свойства являются приоритетными в зависимости от бизнес-потребностей и пользовательских ожиданий. Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

https://habr.com/ru/articles/900330/

#системный_анализ #распределенные_системы #проектирование_систем #анализ_и_проектирование_систем

Отказоустойчивая распределённая архитектура для UX-аналитики

UX-аналитика – это сбор и анализ данных о взаимодействии пользователей с интерфейсом (клики, скроллы, навигация и прочие события). Такие события генерируются в огромных количествах, особенно при большой аудитории приложения. Чтобы эффективно обрабатывать эту информацию, необходима распределённая архитектура, способная масштабироваться под высокий поток событий и обеспечивать отказоустойчивость – т.е. работать надёжно даже при сбоях отдельных компонентов. Также важна возможность обработки данных в реальном времени , чтобы как можно быстрее получать метрики и инсайты об опыте пользователей. В этой статье мы рассмотрим ключевые аспекты такой архитектуры: масштабирование UX-событий, надёжный сбор метрик с устройств (в том числе офлайн), реалтайм-аналитику на основе потоковых технологий (Kafka, Flink, Kafka Streams, ClickHouse) и механизмы гарантированной доставки событий (at-least-once, exactly-once, retry, дедупликация). В результате станет понятно, как правильно спроектированная система UX-аналитики позволяет оперативно находить проблемные места UI, проводить A/B тесты и глубже понимать поведение пользователей.

https://habr.com/ru/articles/897798/

#clickhouse #kafka #flink #kafka_streams #распределенные_системы #отказоустойчивые_системы #аналитика #анализ_данных #анализ_и_проектирование_систем #анализ

Выбор индексов в базах данных для highload-систем

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

https://habr.com/ru/articles/897766/

#postgresql #mysql #mongo #cassandra #sql #nosql #базы_данных #нагрузка #высокая_производительность #распределенные_системы

Три необсуждаемых вопроса о параллельной распределённой обработке данных — чтобы жить стало легче

В публикациях по распределённой параллельной обработке данных весьма редко разбираются сценарии отказа с точки зрения совместной работы воркеров и их влияния друг на друга. На примере решения несложного архитектурного кейса автор покажет, что ответов только на 3 вопроса при проектировании будет достаточно для обеспечения жёстких нефункциональных требований.

https://habr.com/ru/articles/891744/

#конкурентность #распределенные_системы #распределённая_обработка_данных #георезервирование #таскменеджер #таскраннеры #датаинжиниринг #параллелизм

Конфигурирование кластерных систем с помощью Sparky и Rakulang

В общем случае конфигуриоование распределенных и кластерных систем - задача непростая. Для кого может быть полезным инструмент Sparky? Если у вас не используется кубернетес и вам приходится конфигурить / обновлять распределенную инфраструктуры со сложными взаимосвязями. Здесь я покажу несколько примеров не претендующих на исчерпывающее покрытие данной темы Базовая конфигурация Для того что бы все работало необходимо установить Sparky агенты на все настаиваемые ноды вашего кластера и обеспечить сетевую связанность на уровне http/https

https://habr.com/ru/articles/886660/

#инфраструктура #кластеры #devops #распределенные_системы #infrastructureasacode

Apache Flink: использование и автоматическая проверка собственного сериализатора состояния

Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитики. Это мой финальный пост про Apache Flink. В предыдущих частях мы рассматривали процессы сериализации данных, написали кастомный сериализатор, а также покрыли его тестами. В них проверялась поддержка эволюции схемы состояния. Для этого мы реализовали много удобных абстракций, связанных с перезагрузкой Flink MiniCluster, компиляцией тестовых java-классов, использованием их в classpath кластера и так далее. В этом материале мы применим разработанный сериализатор JacksonStateSerializer в бою, а также автоматизируем проверку эволюции схемы для всех наших классов, участвующих в сериализации. Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring . В master-ветке представлен итоговый проект по всей серии. Данная статья соответствует релизной ветке с названием release/11_JacksonEvolvingState . По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже. Список моих постов про Flink:

https://habr.com/ru/companies/ru_mts/articles/878070/

#java #big_data #data_engineering #распределенные_системы #сериализация_данных #эволюция_схемы #Тестирование_Flink

Одна опция TCP-стека спасет приложение от даунтайма

Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком. Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами. Узнать что за опция спасает от даунтайма

https://habr.com/ru/companies/ispring/articles/869800/

#tcp #go #сеть #микросервисы #распределенные_системы #service_mesh #инцидент #kubernetes