#распределенные_системы — Public Fediverse posts

Как fan-out создаёт хвост задержек: эксперимент с параллельными вызовами сервисов

Каждый сервис отвечает быстро, запросы выполняются параллельно, но итоговый ответ всё равно не укладывается в SLA. Причина может быть в самом количестве зависимостей: чем их больше, тем выше вероятность дождаться хотя бы одного медленного ответа. На примере карточки товара разберём, как fan-out влияет на хвостовые задержки, почему растёт p99 и какой ценой можно ускорить ответ, ограничив ожидание необязательных данных. Разобрать эксперимент

https://habr.com/ru/companies/otus/articles/1094850/

#распределенные_системы #нагрузочное_тестирование #tail_latency #параллельные_запросы #микросервисная_архитектура #хвостовые_задержки #p99 #fanout #таймауты #производительность_сервисов

Kafka и ребалансинг: что можно сделать до возникновения проблемы

Ребалансинг в Kafka — не самая популярная и местами не самая понятная тема. Обычно о нём вспоминают только тогда, когда consumer начинает отставать, обработка останавливается, а группа уходит в бесконечные ребалансы. В этой статье попробую простым языком разобраться, почему это происходит, какие проблемы могут к этому привести и что можно сделать, чтобы минимизировать частые ребалансировки. Узнать больше

https://habr.com/ru/companies/magnit/articles/1090266/

#распределенные_системы #высоконагруженные_системы #архитектура_по #отказоустойчивость #kafka #apache_kafka #kafka_streams #ребалансировка #consumer_lag #consumer_group

Паттерны отказоустойчивости

Разбираю 4 паттерна отказоустойчивости: Retry, Deadlines, Rate Limiting и Circuit Breaker. Не только теория, для каждого паттерна показываю реальный код на Go, который его реализует и схемы которые объясняют механику на пальцах.

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

#go #распределенные_системы #jitter #отказоустойчивость #микросервисы #retry #token_bucket #circuit_breaker #rate_limiting #exponential_backoff

NATS: архитектура, модель работы и области применения

Всем привет! Я Алексей Трофимов, .NET-разработчик в компании МУЛЬТИФАКТОР. Попал сюда как раз в тот момент, когда команда заканчивала переход на NATS. В этой статье я расскажу, как устроен NATS и в каких сценариях стоит его выбирать.

https://habr.com/ru/companies/multifactor/articles/1097166/

#распределенные_системы #микросервисы #devops #nats #брокер_сообщений #jetstream #мультифактор

SQL, NoSQL, NewSQL, Distributed SQL: как читать архитектуру СУБД

Для человека, впервые погружающегося в историю систем управления базами данных, последовательность SQL → NoSQL → NewSQL выглядит как диалектическая триада: тезис, антитезис, синтез. Сначала традиционные реляционные СУБД стали основой большинства коммерческих информационных систем, затем на волне NoSQL появились архитектуры, которые ради горизонтального масштабирования отказывались от части привычных реляционных ограничений и гарантий, и наконец направление NewSQL попыталось взять лучшее от обоих миров: SQL и ACID – от реляционных СУБД, горизонтальное масштабирование – от NoSQL.

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

#базы_данных #распределенные_системы #ретроспектива #dba #nosql #история_it #distributed_systems #newsql #cockroachdb

Математика катастрофы: от дифференциальных уравнений до очередей G/G/1 и формулы Кингмана

Знакомая картина: в 3 часа ночи падает база данных, Alertmanager засыпает каналами, через 5 минут сеть восстанавливается, но… система остаётся «мёртвой». CPU на воркерах 100 %, Goodput на нуле, а перезапуск подов только усугубляет ситуацию. Все указывает на то, что вы столкнулись с метастабильным отказом — самым коварным типом аварий в распределённых системах. Меня зовут Артём Баранов, в «Базисе» я занимаюсь автоматизацией и развитием инфраструктуры. В этой статье я хочу рассказать о математике метастабильного отказа и через теорию массового обслуживания — конкретно через модель и формулу Кингмана — проложить мост от математических абстракций к реальным логам, метрикам и алертам. Далее, предложить практикующему SRE-специалисту набор методик для анализа, диагностики и предотвращения катастроф, возникающих в информационных системах по тем или иным причинам (ошибки конфигурирования, сбои «железа» и т. д.). Это позволит инженеру распознать sustaining-эффект по логам и метрикам и осознанно выбрать рычаг (backoff, retry budget, shedding, circuit breaker), а не просто объяснить постфактум, почему возникла предыдущая авария. Углубиться в теорию и практику

https://habr.com/ru/companies/basis/articles/1088474/

#матестабильный_отказ #метастабильность #распределенные_системы #sre #goodput #инженерия #математическое_моделирование #формулы #трафик

Распределённые блокировки в Multi-DC: как перестать дублировать CronJobs

Представьте: вы настроили CronJob, протестировали локально и выкатили в продакшн. Всё работает как часы. А потом решили добавить отказоустойчивости и развернули приложение во втором дата‑центре. И внезапно ваша задача начала выполняться дважды. Это не баг Kubernetes, а фундаментальная проблема синхронизации. Меня зовут Тимофей Салтымаков, я бэкенд‑разработчик в Точка Банк. В статье расскажу, как мы решили проблему дублирующихся CronJob'ов в распределённой системе. Прошли путь от advisory locks до собственной библиотеки, и в итоге поняли, что нужно перестать синхронизировать процессы и начать синхронизировать... время. Поехали!

https://habr.com/ru/companies/tochka/articles/1089556/

#python #распределенные_системы #блокировки #distributed_systems #locks

Резервирование кластера Greengage DB. Часть 3

В данной статье рассмотрим сложные сценарии восстановления кластера Greengage DB, в которых кластер восстанавливается на новом окружении.

https://habr.com/ru/companies/greengage/articles/1090694/

#greengage #резервное_копирование #postgres #pgbackrest #распределенные_системы #greenplum #recovery

Книга: «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд»

Привет, Хаброжители! Сегодня данные играют главенствующую роль в проектировании систем, и нужно обеспечить их масштабируемость, согласованность, надежность, производительность и удобство сопровождения. Необходимо учитывать огромное разнообразие систем хранения данных: реляционных баз данных, хранилищ NoSQL, складов и озер данных, а также облачных и локальных сервисов и встроенных баз данных. С новым обновленным изданием книги вы сможете разобраться в терминологии и решить какой вариант лучше всего подойдет для вашего приложения.

https://habr.com/ru/companies/piter/articles/1090492/

#базы_данных #распределенные_системы #data_engineering #алгоритмы #облачные_сервисы #бэкенд #хранилища_данных #высоконагруженные_системы

Что происходит после нажатия Play. Разбираем архитектуру Spotify

Всем привет. На днях попалась информация интересная и захотелось разобраться в сервисе, которым пользуются миллионы людей – это Spotify. На первый взгляд всё очень просто, нашли песню, нажали Play, музыка заиграла, но, если вспомнить, что за этим приложением стоят миллионы пользователей и миллионы треков, всё становится гораздо сложнее и интереснее. Где физически лежит музыка? Почему один и тот же трек существует в нескольких версиях? Кто отправляет аудио пользователю? Почему Spotify не отдаёт весь файл через свой backend? Как музыка успевает загрузиться раньше, чем мы до неё дослушали? И откуда приложение знает, где мы остановились на другом устройстве? Давайте разберёмся.

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

#spotify #архитектура #system_design #распределенные_системы #высоконагруженные_системы #cdn #стриминг #аудиостриминг #кеширование #буферизация

Нужна ли вашей распределённой СУБД византийская отказоустойчивость?

Когда инженер проектирует распределённую систему, возникает естественное желание обеспечить сложную и хрупкую архитектуру максимально сильными гарантиями отказоустойчивости и согласованности данных. На первый взгляд кажется, что чем строже модель отказов, тем надёжнее система. Но отказоустойчивость – это не ручка громкости, которую можно выкрутить на максимум. Разные модели отказов решают разные задачи: в одном случае система должна пережить падение узла, потерю связи или зависание реплики, в другом – договориться о едином порядке событий, даже если часть участников ведёт себя так, что их сообщениям уже нельзя доверять.

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

#cft #bft #valkey #ретроспектива #распределенные_системы #базы_данных #субд #кворум #репликация #консенсус

Kubernetes просто, часть 1: зачем Kubernetes, устройство кластера

Kubernetes без магии и заучивания команд. Разберёмся, зачем он вообще нужен, как устроен кластер, чем Control Plane отличается от Worker Nodes и какую роль играют Pod, Scheduler, kubelet, etcd и другие основные компоненты .

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

#девопс #кубернетес #системное_администрирование #распределенные_системы #сетевые_технологии #обучение #систем_дизайн

Модульный монолит в суровых условиях: как я написал фреймворк для производства

Всё началось с задачи мониторинга сетевой инфраструктуры и скрипта на python. С решением давних и новых проблем возникали следующие, которые выстроили архитектуру ядра программы — которое я выделил в отдельный фреймворк. Внутри : Эволюция, Архитектура, Отказоустойчивость, Федерация, Передача сообщений

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

#Архитектура_ПО #монолит #распределенные_системы #многопоточность #производство #автоматизация #python #отказоустойчивость #экономия

Kafka Connect без магии: как переносить данные и не писать еще один сервис

Привет, бойцы , вы готовы победить перенос данных? Есть задача: перенести данные из PostgreSQL в Kafka. Первая мысль: написать небольшой сервис. Он будет выполнять SELECT , превращать строки в сообщения и отправлять их через Kafka Producer. На схеме все выглядит почти безобидно:

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

#apache_kafka #kafka_connect #source_connector #smt #интеграция_данных #потоковая_обработка #распределенные_системы #postgresql

Наносервисы — как довести распределенные системы до логического конца

Мы рассмотрим новый фреймворк Areg SDK, идея которого, по моему мнению, может задать новый стандарт в распределенных системах. От идеи микросервисов, где компонент общается с другими компонентами, мы выходим на уровень выше - структуры бесшовно общаются со структурами на других потоках и хостах в эталонной синхронизации. Какой подход выбрали коллеги и причем тут бог Солнца? Давайте выясним.

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

#c++ #распределенные_системы #многопоточность

[Перевод] DSL позволяют надежно использовать LLM

LLM генерируют код невероятно быстро, но чтобы гарантировать, что они создают именно то, что задумано, им нужны четкие границы. Абстракции и предметно-ориентированные языки (DSL) создают надежную оболочку, которая направляет LLM с самого начала. Пример Tickloom — предметной модели и DSL для иллюстрации поведения распределенных систем — показывает, как мы можем использовать LLM в качестве партнера для итеративного создания DSL и как естественно-языковой интерфейс для его использования. Такой DSL может выступать в качестве единственного источника истины для программных систем в мире LLM. Современные LLM обладают невероятными возможностями. Они могут генерировать большие объемы кода, а иногда и целые системы, основываясь лишь на высокоуровневом описании на естественном языке. Важное предположение здесь заключается в том, что «намерение» относительно того, что необходимо построить, четко сформулировано с помощью точных слов, которые LLM могут сопоставить со строительными блоками кода. Однако здесь стоит отметить два важных момента: ограничения предварительной спецификации и то, как дизайн выявляется в процессе реализации.

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

#dsl #распределенные_системы #aiagent #llm #ddd #semantic_model #java #distributed_systems

[Перевод] DSL позволяют надежно использовать LLM

LLM генерируют код невероятно быстро, но чтобы гарантировать, что они создают именно то, что задумано, им нужны четкие границы. Абстракции и предметно-ориентированные языки (DSL) создают надежную оболочку, которая направляет LLM с самого начала. Пример Tickloom — предметной модели и DSL для иллюстрации поведения распределенных систем — показывает, как мы можем использовать LLM в качестве партнера для итеративного создания DSL и как естественно-языковой интерфейс для его использования. Такой DSL может выступать в качестве единственного источника истины для программных систем в мире LLM. Современные LLM обладают невероятными возможностями. Они могут генерировать большие объемы кода, а иногда и целые системы, основываясь лишь на высокоуровневом описании на естественном языке. Важное предположение здесь заключается в том, что «намерение» относительно того, что необходимо построить, четко сформулировано с помощью точных слов, которые LLM могут сопоставить со строительными блоками кода. Однако здесь стоит отметить два важных момента: ограничения предварительной спецификации и то, как дизайн выявляется в процессе реализации.

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

#dsl #распределенные_системы #aiagent #llm #ddd #semantic_model #java #distributed_systems

Я думал, что 16 воркеров ускорят обработку задач в 16 раз. Но что‑то пошло не так

Недавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач. Когда основная функциональность была готова, я понял, что не знаю, как система ведёт себя под нагрузкой . Поэтому вместо того, чтобы добавлять очередную фичу, я решил провести простой эксперимент. Взять одинаковый набор задач и постепенно увеличивать количество воркеров. Первые результаты выглядели именно так, как я ожидал. А потом масштабирование внезапно остановилось. Увеличение количества воркеров с 16 до 32 практически не дало прироста производительности, а при 64 воркерах ситуация стала ещё интереснее: задачи, которые должны были выполняться около 0.5 секунды, начали занимать больше секунды. Первой моей мыслью было, что я упёрся в PostgreSQL. Оказалось, что нет.

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

#python #celery #worker #optimisation #backend #многопоточность #асинхронность #тестирование #docker #распределенные_системы

Как тестировать распределенные системы: тайм-ауты, дубликаты, Saga и частичные отказы

Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными. Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет. Самое очевидное решение — повторить запрос. И получить второе списание. В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло. Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя. В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы. Почему распределенную систему нельзя тестировать как обычное приложение Возьмем простой пример — оплату заказа в интернет-магазине.

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

#распределенные_системы #тестирование #таймауты #идемпотентность #Saga #Circuit_Breaker #Fault_Injection #Chaos_Engineering #eventual_consistency #микросервисы

[Перевод] Большинство ошибок при System Design ускользает из виду

Пять пробелов, которые не видны на архитектурных блок-схемах. Пользователь нажимает « Place Order» (Сделать заказ) . API возвращает 200 OK. Заказ появляется в базе данных. На странице оформления заказа выводится сообщение «success» (успех). Извне всё выглядит нормально. А потом в службу поддержки прилетает тикет.

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

#system_design #архитектура #распределенные_системы #проектирование_систем

Смартфон как элемент эшелонированной системы обнаружения БПЛА: архитектура распределенной сенсорной сети

Представьте, что любой человек, выйдя на улицу или посмотрев в окно, может стать частью распределенной системы раннего обнаружения воздушных угроз. Не как оператор или специалист, а как источник дополнительного сенсорного наблюдения. Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА. Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов. Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.

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

#БПЛА #обнаружение_дронов #краудсорсинг #распределенные_системы #Edge_Computing #TinyML #фильтр_Калмана #сенсорные_сети #триангуляция #TDoA

Строим сеть на Qeli

Для понимания сути вопроса - немного истории: Жила-была CRM, частная, корпоративная - хостилась на удаленном сервере у надежного хостера, сотрудники из разных филиалов заходили в нее и работали свою работу. Никаких тысяч серверов, никакого кровавого энтерпрайза - всё тихо, мирно, почти по-домашнему. И работало это долго, пока враги не начали ломать интернет. У части пользователей пропадал доступ к сайту, работать они не могли - сначала помогал VPN, но потом враги начали бороться и с VPN. Попробовали разнести точки входа по серверам по локациям, сохранив единую базу - враги начали блокировать межсерверные соединения. А тут еще у одного знакомого вдруг сервер отключили (другие враги, не местные) - значит, надо забирать базу локально. У другого знакомого локальный сервер поломался - значит, нужно делать удаленную резервную площадку. Ну ок, системы разнесли, резервы понастроили - а как к ним обращаться, если напрямую нет соединения? Ну прокинули очередной VPN, повесили на какой-то IP адрес канала - а завтра этот канал не работает и этот адрес теперь недоступен, надо менять. Утро начинается не с кофе, утро начинается с проверки "что сегодня и как заблокировали".

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

#сети #распределенные_системы

Kafka Consumer в тестовой автоматизации: архитектурный разбор

Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка. End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается. В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом. Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

https://habr.com/ru/companies/it_sense/articles/1051890/

#kafka #kafka_consumer #kafka_в_тестировании #qa_automation #sasl #асинхронное_тестирование #aiагенты #allure #consumer_group #распределенные_системы

[Перевод] System Design: проектируем Rate Limiter, ограничитель запросов

В задаче проектирования Rate Limiter важны сразу несколько вещей: выбор алгоритма лимитирования, централизованное хранение состояния, работа через API Gateway и масштабирование до 1 млн запросов в секунду. В статье разберём, почему для такого сценария часто выбирают Token Bucket, как использовать Redis для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.

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

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

Пять самых крупных ошибок, которые допускают компании при внедрении SRE

SRE часто внедряют как набор инструментов, дашбордов и новых должностей, но через полгода команда всё так же тушит инциденты по ночам, а бюджеты ошибок живут только в таблицах. В статье разбираем 5 типичных провалов при внедрении SRE: от формального переименования эксплуатации до поспешной покупки AIOps без нормального observability. Это разбор о том, почему надежность ломается не только в инфраструктуре, но и в процессах, метриках, найме и управленческих стимулах. Разобрать ошибки

https://habr.com/ru/companies/otus/articles/1040050/

#Site_Reliability_Engineering #SRE #надежность_систем #распределенные_системы #мониторинг #observability #slo #бюджет_ошибок #инциденты

Баги, которые нас воспитали: инженерные истории с Go Loto

Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать. На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером. Спойлер: все выжили. Но стали другими людьми.

https://habr.com/ru/companies/avito/articles/1037846/

#go #bloat #vacuum #микросервисы #распределенные_системы #нагрузочное_тестирование #postmortem

Иллюзия сохранности, или Бэкап, который не спасает

Случай, произошедший со стартапом PocketOS, выглядел бы комичным, если бы не обернулся реальной катастрофой. ИИ-агент Cursor, работавший на базе Claude Opus, за девять секунд уничтожил не только основную базу данных компании, но и все резервные копии.

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

#бэкап #резервное_копирование #искусственный_интеллект #информационная_безопасность #распределенные_системы

[Перевод] System Design: проектируем Dropbox, сервис для хранения и обмена файлами

Самая интересная часть в проектировании Dropbox — не хранение метаданных, а работа с самими файлами: как загружать большие объекты без перегрузки своих серверов, как возобновлять загрузку после обрыва и как быстро синхронизировать изменения с другими устройствами. В статье подробно разберём, как всё это складывается в работающую архитектуру облачного хранилища.

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

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

[Перевод] Идемпотентность в System Design: полный пример

Идемпотентность в System Design: полный пример Идемпотентность часто упоминается при проектировании систем (system design). Ниже будет простыми словами объяснено, что это такое, далее мы разберём основные детали идемпотентности, часто понимаемые неверно и, наконец, проиллюстрируем её на полном примере. Что такое идемпотентность? Операция является идемпотентной, если при однократном или многократном выполнении она всякий раз даёт один и тот же результат.

https://habr.com/ru/companies/piter/articles/1034544/

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

Строим шину данных для микросервисов на ZeroMQ: failover, гарантии доставки и E2E-шифрование

Асинхронная клиент-серверная библиотека для обмена сообщениями между микросервисами на базе ZeroMQ. Реализует гарантированную доставку сообщений (At-Least-Once) с персистентной файловой очередью при обрывах связи, автоматический failover сервера переадресации (клиенты могут подхватывать роль сервера на лету) и два уровня защиты: шифрование канала (CurveZMQ) и сквозное шифрование сообщений (HMAC). Лёгкая альтернатива брокерам вроде RabbitMQ, не требующая отдельного сервера.

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

#python #zeromq #zmq #failover #atleastonce #endtoend_шифрование #микросервисы #распределенные_системы #hmac #криптография