home.social

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

Live and recent posts from across the Fediverse tagged #распределённые_системы, aggregated by home.social.

fetched live
  1. Платёж списывается дважды. Найдите причину в коде, который прошёл ревью

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

    habr.com/ru/companies/otus/art

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

  2. Дайте нормально поработать или я сделаю это сам

    Получив на этот и остальные вопросы утвердительный ответ, я принял оффер. Каково же было мое удивление в первый день работы, когда мне дали RDP‑доступ к Windows‑тачке — вся работа организовывалась через нее. Маленькое отступление: последний раз я работал на Windows в 2011 году, еще на XP. Для читателей (да и для меня в какой‑то момент) самым простым и логичным вариантом было бы продолжить поиск работы, но работа на непривычной для меня операционной системе по факту была единственным моментом, который показался неподходящим. После некоторых попыток обустроить быт, выяснилось, что даже WSL там сильно порезанный, с собственными репозиториями и старыми операционками. Естественно, с личных устройств до удаленной машины заблокировано примерно все.

    habr.com/ru/articles/1090922/

    #Прокси #Proxy #SOCKS5 #WebSocket #маршрутизация #распределённые_системы #Docker #DevOps #Open_Source #сетевые_технологии

  3. Два человека правят один документ офлайн. Изобретаем гугл-док без сервера-арбитра

    Гугл-док держится на сервере, который выстраивает все правки в один порядок. Убираем сервер: две копии правятся офлайн и обязаны сойтись символ в символ. Разбираю, как это устроено внутри, на движках, которые сам портировал на Go.

    habr.com/ru/articles/1083696/

    #CRDT #совместное_редактирование #offlinefirst #распределённые_системы #синхронизация #YATA #Yjs #Loro #Go #localfirst

  4. Heartbeat: как мы создали систему управления системой вместо обычных сигналов

    Привет! Меня зовут Александр Илларионов, я бэкенд‑разработчик в Altenar. Мы работаем на довольно сложном и при этом очень интересном рынке: собираем данные о спортивных матчах со всего мира — например, время и место их проведения, описания чемпионатов и участников, а также вероятности наступления ключевых событий вроде голов, аутов и пенальти. И всё это в live‑режиме. В этой статье рассказываю, как мы переосмыслили роль Heartbeat‑компонента в нашей системе — от обычного сигнала до инструмента, который реально управляет работой всей системы. Наш опыт будет полезен тем, кто работает с .NET, распределёнными системами или строит инфраструктуру под высоконагруженные real‑time потоки данных.

    habr.com/ru/articles/1078782/

    #heartbeat #микросервисы #kubernetes #probes #Health_Checks #NET #C# #мониторинг #распределённые_системы #спортивные_данные

  5. EvertyCloud: что я сделал что-бы компании перестали арендовать емкость

    Меня зовут Артур Валиев. За последнее время я сделал несколько проектов на Rust + Iced, которые со стороны действительно можно принять за отдельные программы. EvertyDesk Next — удалённый доступ. EvertyDisplay — виртуальные мониторы. EvertyCloud — облачные и сетевые диски. Но я всё меньше воспринимаю их как три разных продукта. На самом деле это одна система. И сегодня я хочу наконец объяснить, что именно я пытаюсь построить. Моя мысль довольно простая: компьютер не обязан заканчиваться там, где заканчивается его корпус.

    habr.com/ru/articles/1083616/

    #Rust #Iced #EvertyCloud #EvertyDesk #EvertyDisplay #распределённые_системы #облачное_хранилище #TCP #UDP #rclone

  6. Как защитить платежный API от двойных списаний с помощью идемпотентности

    Пользователь нажал кнопку оплаты один раз, но деньги списались дважды — такой сценарий возникает не из‑за редкой ошибки, а из‑за обычной неопределённости в распределённых системах. Если клиент не получил ответ, сервер уже не может понять, выполнилась операция или нет. Разберём, как спроектировать ключи идемпотентности, избежать гонок при повторных запросах и построить схему, которая сохранит корректность платежей даже при сбоях сети и параллельной обработке. Читать гайд

    habr.com/ru/companies/otus/art

    #идемпотентность #распределённые_системы #микросервисы #API #backend #платежные_системы #отказоустойчивость #PostgreSQL #конкурентный_доступ #архитектура_ПО

  7. Как пережить резкий рост нагрузки в Kubernetes без надежды только на автоскейлинг

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

    habr.com/ru/companies/otus/art

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

  8. AVM изнутри задачи, сбои и состояние виртуальных машин

    В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин. Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM – собственная система управления виртуализацией.

    habr.com/ru/articles/1075782/

    #Aeza #AVM #виртуализация #виртуальные_машины #libvirt #gRPC #распределённые_системы #отказоустойчивость #идемпотентность #state_machine

  9. Распределённые вычисления: гарантия завершения на исполнителях, которые вам ничего не должны

    Если вы ведете pet‑проекты, требующие большого количества вычислений, то наверняка сталкивались с проблемой их - вычислений - оркестрации. Содержать личный кластер позволить себе могут далеко не все, а каждая арендная платформа имеет свой специфический инструментарий интеграции и свои ограничения, а хуже всего, что ни одна из них не имеет гарантий полного выполнения. Вдобавок к этому, еще и не хотелось бы завязываться на одну конкретную площадку, как минимум потому, что некоторые провайдеры дают бесплатные возобновляемые квоты, и тратить их, вместо своих кровно заработанных, гораздо приятнее. В данной статье будет рассматриваться пример с арендными GPU , однако все основные тезисы полностью переносимы и на другие сценарии использования. У вас, скорее всего, уже открыт десяток разнообразных вкладок: какая‑нибудь платформа с бесплатными недельными лимитами, вроде Kaggle ; что‑нибудь с бесплатными возобновляемыми кредитами, на подобии Lightning AI ; возможно, пара площадок со спотовыми машинами по цене чашки кофе, например Vast , но с оговоркой — никто не обещает, что машину не заберут, или у ее владельца не отвалится сеть. Каждый вариант в отдельности выглядит как «ну, на пару экспериментов может быть и хватит» с различной долей допущения. Все вместе они выглядят как кластер. Нюанс в том, что кластером они становятся не сами: между « у меня есть пяток площадок » и « моя задача точно доедет до конца и не ляжет в непредсказуемый момент » находится довольно много инженерной работы, и почти вся она — не про площадку, а про грамотную оркестрацию. Эту работу я выполнил для своего проекта и хочу поделиться тем, из чего она состояла. Многие решения оказались неочевидными, а добрая половина появилась лишь после того, как самый явный вариант сломался. Итак, приступаем... Где взять гарантию, которая не существует?

    habr.com/ru/articles/1073954/

    #распределённые_системы #отказоустойчивость #MLOps #gpu #архитектура_по #воспроизводимость_моделей #оркестрация #обучение_моделей #облачные_вычисления #проектирование

  10. Цена, которой не существовало: две недели поиска бага, который не видел мониторинг

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

    habr.com/ru/articles/1070518/

    #кэширование #распределённые_системы #консистентность_данных #мониторинг #наблюдаемость #метрики #разбор_инцидента

  11. [Перевод] Как потеря 17% сессий запустила цепную реакцию в инфраструктуре Discord

    25 марта 2026 года голосовая и видеосвязь Discord перестала нормально работать для большинства пользователей. Причиной стал не один большой сбой, а цепочка событий: изменение конфигурации Kubernetes привело к потере части пользовательских сессий, затем система столкнулась с лавиной переподключений и новыми узкими местами в инфраструктуре. В статье команда Discord разбирает этот инцидент изнутри: как 17% остановленных сессий запустили каскадный отказ, почему механизмы восстановления сами стали источником нагрузки и какие архитектурные изменения помогли сделать систему устойчивее. Читать разбор

    habr.com/ru/companies/otus/art

    #распределённые_системы #discord #kubernetes #Elixir #erlang #производительность #микросервисы #масштабирование

  12. OpenTelemetry как единый стандарт наблюдаемости для распределённых систем

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

    habr.com/ru/companies/otus/art

    #OpenTelemetry #наблюдаемость #распределённые_системы #телеметрия #метрики #логирование #распределённая_трассировка #OpenTelemetry_Collector #OTLP #сэмплирование

  13. Как сделать приложение быстрым и надёжным с помощью межсервисных запросов

    Микросервисы обещают независимость и гибкость, но вместе с этим добавляют новый класс проблем: задержки между сервисами, каскадные сбои и сложность управления зависимостями. В статье разберём, какие подходы помогают выстроить устойчивое межсервисное взаимодействие — от агрегаторов и API Gateway до GraphQL и CQRS — и где у каждого решения есть свои ограничения.

    habr.com/ru/companies/otus/art

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

  14. [Перевод] 9 AI-агентов делят одну API-квоту. Почему обычные ретраи только ломают систему

    Девять AI-агентов делят одну API-квоту — и один ответ 429 быстро превращается в каскадный отказ всей системы. В этой статье разбираемся, почему стандартные ретраи и jitter перестают работать при общей квоте, и показывает архитектуру Rate Governor: с приоритетами, общим пулом токенов, предиктивным Circuit Breaker и координацией между агентами. Изучить паттерны

    habr.com/ru/companies/otus/art

    #AIагенты #мультиагентные_системы #rate_limiting #ограничение_запросов #APIквоты #Circuit_Breaker #распределённые_системы #backpressure #Redis

  15. Eventual Consistency: как мы починили тормоза апрува и сломали бюджет

    Мы убрали одну блокировку, чтобы апрувы перестали тормозить. Через несколько недель из-за этого клиент пробил квартальный бюджет – а наша система этого даже не заметила. B2B travel SaaS, конец 2016-го. Два руководителя финансового департамента одновременно открыли форму апрува, оба увидели один и тот же остаток, и каждый одобрил поездку, которая по отдельности в бюджет вписывалась. Вместе они пробили лимит. Узнали мы об этом из звонка клиента, не из алерта. Дальше – три вопроса про eventual consistency, которые стоит задать до архитектуры, а не на разборе инцидента.

    habr.com/ru/articles/1042256/

    #eventual_consistency #согласованность_данных #CQRS #оптимистичная_блокировка #EF_Core #проекции #saga #идемпотентность #распределённые_системы #read_model

  16. Idempotency keys: 5 граблей, которые мы поймали на проде

    Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку. Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

    habr.com/ru/articles/1039860/

    #идемпотентность #idempotency #платежи #распределённые_системы #NET #C# #API #intentkey #race_condition #грабли

  17. Cache is hard — почему инвалидация кэша — это проблема согласованности, а не производительности

    Кэш часто воспринимают как простой способ ускорить систему: положили данные ближе к приложению — получили быстрый ответ. Но на практике главная сложность начинается не с производительности, а с согласованности. Когда данные меняются, кэш может начать «врать»: показывать старые остатки, устаревшие статусы или разные версии одной и той же сущности разным пользователям. В статье разбираем, почему инвалидация кэша — это архитектурная проблема, как TTL, события, CDC и lease‑подходы влияют на консистентность и когда кэш лучше вообще не использовать.

    habr.com/ru/companies/otus/art

    #кэширование #инвалидация_кэша #согласованность_данных #распределённые_системы #Redis #PostgreSQL #CDC #Kafka #TTL #высоконагруженные_системы

  18. Advisory Locks в PostgreSQL: блокировки уровня приложения, о которых мало кто знает

    Привет, Хабр! PostgreSQL умеет блокировать строки ( SELECT ... FOR UPDATE ) и таблицы ( LOCK TABLE ). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение. Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет. Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

    habr.com/ru/companies/otus/art

    #psql #advisory_locks #PostgreSQL_блокировки #блокировки_в_БД #конкурентный_доступ #идемпотентность #микросервисная_архитектура #распределённые_системы

  19. Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

    Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

    habr.com/ru/articles/1006566/

    #искусственный_интеллект #ИИагенты #многоагентные_системы #децентрализованные_сети #распределённые_системы #протоколы_взаимодействия #автономные_агенты #HMP #HyperCortex_Mesh_Protocol #peertopeer

  20. [Перевод] Почему Erlang до сих пор король отказоустойчивых систем

    Задумывались ли вы когда-нибудь, как построить самое стабильное приложение в мире? Какими свойствами оно должно обладать и какие архитектурные подходы делают это возможным? Впечатляет, что приложения вроде Discord и WhatsApp выдерживают миллионы одновременных пользователей, тогда как другие задыхаются уже на нескольких тысячах. Сегодня посмотрим, как Erlang позволяет обрабатывать огромную нагрузку и при этом держать систему живой и стабильной. К архитектуре Erlang

    habr.com/ru/companies/otus/art

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

  21. [Перевод] ACID-свойства транзакций в SQL

    Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо. Все это в свою очередь должно гарантировать целостность данных. Но что это вообще такое и на что влияет? А ответ очень простой. Обеспечивая целостность данных, мы предупреждаем ситуации, когда, к примеру, деньги со счета списались, но получателю так и не пришли. Или заказ оформился, а складские остатки не обновились. В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

    habr.com/ru/companies/otus/art

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

  22. [Перевод] Corrosion от Fly.io: сервис-дискавери на Rust и SQLite без кластера

    Когда у вас есть глобальная платформа с тысячами машин по всему миру, самая болезненная часть — не сервера и не сеть, а согласование того, кто и где сейчас жив. Команда Fly.io уже успела пройти через зависшие прокси по всему парку, «заразный» дедлок в Rust, DDL-миграции в глобальной базе состояния и истории, когда попытки восстановить соединение с Consul превращали инфраструктуру в обогреватель аплинков. В статье разбирается, как из этих факапов родился Corrosion — сервис-дискавери на Rust и SQLite без распределённого консенсуса и центрального хранилища, построенный по мотивам протоколов маршрутизации вроде OSPF и CRDT-репликации. Это история не только о том, как устроен инструмент, но и о том, какие архитектурные решения для распределённого состояния реально живут в продакшене, а какие красиво смотрятся только на диаграммах. Разобрать Corrosion

    habr.com/ru/companies/otus/art

    #распределённые_системы #сервисдискавери #gossipпротокол #CRDT_репликация #Rust #отказоустойчивость_сервисов #протоколы_маршрутизации_OSPF #инцидентменеджмент_SRE

  23. [Перевод] Всё, что я знаю о хорошем системном дизайне

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

    habr.com/ru/companies/otus/art

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

  24. Как реализовать CRDT-структуры в Go для офлайн-режима

    Привет, Хабр! Сегодня мы поговорим о том, как справиться с синхронизацией данных в офлайн-режиме так, чтобы не сваливать на пользователя головную боль слияния конфликтов. Вы наверняка замечали, что многие современные приложения — будь то заметки, менеджеры задач или вики-редакторы — позволяют работать оффлайн на нескольких устройствах, а при подключении к сети автоматически объединяют изменения. Задача разработчика в таком случае сделать максимально гладкую синхронизацию одновременно изменённых данных на разных узлах, ideally без участия пользователя в разрешении конфликтов. Классические решения вроде Operational Transformation давно применяются, например, в совместном редактировании документов. Но сегодня я хочу рассказать про другой подход — CRDT . Перейти к разбору CRDT

    habr.com/ru/companies/otus/art

    #golang #crdt #распределённые_системы #синхронизация_данных #офлайнсинхронизация #репликация_данных #консистентность_данных

  25. [Перевод] Когда повторы убивают: метастабильные отказы в распределённых системах

    Бывают сбои, которые не исчезают после устранения причины: система залипает, полезная пропускная способность почти нулевая, а петли обратной связи удерживают отказ. В статье формализуем это как метастабильные отказы, разберем цикл «стабильное → уязвимое → метастабильное», характерные метрики и «скрытую ёмкость». Обсудим практики сохранения полезной пропускной способности под перегрузкой: бюджет повторов, приоритеты и отбрасывание запросов, обслуживание «последних первыми», грамотное управление очередями и автомат защиты. Читать про метастабильность

    habr.com/ru/companies/otus/art

    #метастабильность #метастабильный_отказ #распределённые_системы #петли_обратной_связи #work_amplification #retry_budget #goodput

  26. Когда open/close уже мало: как мы реализовали протокол доступа к 20 000 машин через Bluetooth

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

    habr.com/ru/companies/citydriv

    #bluetooth #каршеринг #IoT #мобильная_разработка #протоколы_связи #обновление_прошивок #интеграция_оборудования #умные_устройства #grafana #распределённые_системы

  27. Почему сложно писать о передовых информационных технологиях?

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

    Веб-сайт: causa-arcana.com/blog/2021/08/
    Medium: medium.com/causa-arcana/writin
    IPNS: k51qzi5uqu5ditckag7gw12c301kwx
    Tor: a4xu7f2nwqxrraaj3qfiao5cgfyrkp
    Yggdrasil: y.causa-arcana.com/blog/2021/0

    #информатика #технологии #децентрализация #распределённые_системы
    @rf

Share on Mastodon

Enter the server where you have an account.