Распределённые системы *

Привет, Хабр! Меня зовут Сергей, я работают в компании InfoWatch разработчиком на продукте ARMA Стена (NGFW). Подробнее о том, что такое ARMA Стена, можно прочитать тут.

В этой статье я хочу поделиться опытом применения метода формальной верификации в решении практической бизнес-задачи.

Сразу оговорюсь, что в статье используется TLA+, без введения в инструмент, чтобы не увеличивать объём статьи. Подробнее про инструмент вы можете почитать на сайте создателя, тут и тут. Необходимые объяснения даются по ходу изложения.

Статья состоит из двух частей:

1) Что такое формальная верификация и где она применятся

2) Решение бизнес-задачи в NGFW

Во время инференса LLM не выполняется побочных эффектов, вместо этого генерируется последовательность токенов, которые можно интерпретировать как намерение вызвать инструмент. Это напоминает мне ту часть шаблона transactional outbox, в которой намерение сущности (entity) отправить запрос внешней системе записывается в специальную таблицу, а не реализуется сущностью самостоятельно.

В статье приведен proof-of-concept модели выполнения, вдохновленной chat completion, в которой управление возвращается вызывающей стороне при необходимости выполнить побочный эффект.

Привет, Хабр!

Если вы когда-нибудь сталкивались с задачей запуска сотен изолированных фоновых процессов на одном сервере (будь то парсеры для клиентов, торговые боты или обработчики данных в SaaS), то вы знаете, как быстро всё усложняется.

Можно, конечно, вручную поднимать Docker-контейнеры и писать костыли для мониторинга. Можно развернуть полноценный Kubernetes, но для одной ноды это часто — оверкилл, требующий отдельного администратора. Можно использовать Celery, но он управляет задачами, а не контейнерами, и изоляция на уровне процессов — это не тоже самое, что изоляция на уровне контейнеров.

Мы столкнулись с этой болью и написали инструмент, который закрывает этот пробел. Встречайте: RedTailFox — легковесный оркестратор на Python, который управляет Docker-контейнерами с вашими воркерами на одном сервере. Он сам решает, когда поднять новый контейнер, сам следит за здоровьем слотов и сам себя чинит.

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

Есть ощущение, что мы сейчас живём в странный период: LLM-агенты уже умеют “делать работу”, но ещё не умеют быть предсказуемыми.

На демке всё выглядит идеально:

• один агент пишет код,
• второй — тесты,
• третий — делает ревью,
• четвёртый — собирает артефакты и отчёт,
• пятый — «оператор», который всё это оркестрирует.

Первые пару запусков ты сидишь и думаешь: «Ну всё. Завтра индустрия будет другой». На третьем запуске агент уверенно сообщает: «Я исправил проблему», и одновременно:

Привет, Хабр. Меня зовут Олег Жуковец. Я руководитель команды «Экосистема» в Tarantool R&D компании VK Tech.

Многие разработчики сталкивались с ситуацией, когда запросы к базе данных выполняются быстро, индексы настроены, оборудование справляется с нагрузкой, но конечное приложение все равно работает медленно. Нередко проблема кроется не в самой базе данных, а в некорректно реализованном клиенте, который может стать «бутылочным горлышком» для всего ИТ-ландшафта. Именно поэтому оптимизация клиентов для работы с БД имеет важное значение.

В этой статье я на примере коннектора к Tarantool расскажу о доступных и простых оптимизациях клиента для БД, которые позволяют минимизировать аллокации и число горутин, чтобы выкрутить скорость обработки запросов (RPS) на максимум.

Данная статья описывает библиотеку muRPC для создания сервера и клиента для протокола JSON-RPC. Режим работы предполагает, что один из клиентов JSON-RPC предоставляет какие-то методы и сообщает об этом серверу. Тогда другие клиенты JSON-RPC могут эти методы вызывать и получать ответ. Сервер предоставляет маршрутизацию и валидацию сообщений между клиентами.

Область применения — это любые системы, где требуется обмен сообщениями, удобно соединяемый с вызовом программных функций.

Продолжаю рубрику «Мысли вслух». Цель данной публикации – описать алгоритмы и новизну моих исследований по созданию кластера СУБД с горизонтальным масштабированием производительности – распределенного вычислительного кластера (РВК). Набралась очередная порция материалов в следствие новых изысканий и натурных экспериментов, которыми и делюсь. Сегодня речь пойдет о возможных протоколах работы РВК. Создание распределённого кластера СУБД обычно приносит серьёзные потери в производительности одиночных операций, плюс сложности в разработке, эксплуатации и сопровождении. Цель моей работы – создать РВК без этих недостатков.

Привет, Хаброжители! «System Design. Распределенные системы. Подготовка к сложному интервью» — это практическое руководство для инженеров и архитекторов, которое поможет справиться с самыми трудными техническими заданиями. Алекс Сюй и Сан Лэм предлагают стратегию, проверенную на практике, пошаговые алгоритмы и реальные примеры, позволяющие научить вас проектировать масштабируемые системы — от новостной ленты до поисковых сервисов и чат-приложений.

Для задач аналитики Zeppelin - это чуть ли не находка. Он может в одной книжке исполнять код на любом языке (был бы интерпретатор), выводить его в виде красивых табличек, графиков и в любом другом виде, который удобен. И на Хабре есть много статей, посвященных плюсом данного решения для задач аналитики.

В результате в аналитический отдел ТКБ Инвестмент Партнерс данный инструмент проник достаточно глубоко: на нем писались аналитические отчеты для разных отделов, расчетные таблицы, которые затем отсылались в дашборды, также данными книжками могли пользоваться все, кто знал какие-либо языки программирования.

И мы попали в зависимость от него. Панацея, которая должна была стать легким решением для (почти) любой задачи превратилась в наше проклятие. Из-за проблем с данной системой на нас приходило по 5-7 тикеров в неделю, а также потерей доверия к нашим сервисам.

Привет, Хаброжители! Интервью по System Design (проектированию ИТ-систем) очень популярны у работодателей, на них легко проверить ваши навыки общения и оценить умение решать реальные задачи.

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

Это явление давно известно в архитектуре вычислительных систем как разрыв между процессором и памятью (или Memory Wall). Сегодня он определяет производительность серверов, баз данных, платформ данных и AI/ML-платформ сильнее, чем выбор конкретной модели процессора или видеокарты. А в будущем определит то, какие продукты и решения индустрия будет использовать для решения задачи хранения данных.

Привет! Я Александр Гришин, руководитель по развитию продуктов хранения данных в Selectel. В этой статье я попробую подробно разобрать, что такое этот ваш разрыв между процессором и памятью, как он сформировался, как устроена иерархия памяти в сервере и почему эти ограничения подталкивают индустрию к новым архитектурам и решениям. Погнали!

Загадка: во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2? 

Ответ: в 2,5 раза!

Привет! Меня зовут Стёпа, и я разработчик в Яндекс Go. Я хочу поделиться тем, как математика может встречаться в самых неожиданных местах — даже в такой рутинной задаче, как настройка интервала поллинга. В статье я рассмотрю модельный пример, который встречался каждому разработчику, и просчитаю его с математической точки зрения, использовав базовые факты из теории вероятностей и статистики.

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

Если к этому добавить интеграцию между разными системами и наличие общей межсистемной шины, архитектурная картина становится еще более многослойной и уязвимой к сбоям.

Где именно все может сломаться

Предположим, у нас две системы:

Мультиагентные системы часто собирают по привычной схеме «оркестратор + набор независимых сервисов-агентов» — и довольно быстро приходят к распределённому монолиту. В статье разберем, почему при интерфейсе на естественном языке нельзя принудительно обеспечивать контракты как в API, из-за чего усложняются маршрутизация, изменения начинают каскадить, а общий контекст превращается в разделяемое состояние. И почему в такой ситуации иногда разумнее признать монолит — и управлять оркестрацией как единым целым.

CedrusData Engine — это lakehouse-движок, основанный на Trino. На реальных нагрузках наш продукт рутинно превосходит по производительности другие технологии (Trino, Doris, Dremio, StarRocks) в 1.5-3 раза, с еще более значительным отрывом от устаревших Greenplum и Impala. Эти результаты — следствие постоянных вложений в разработку новейших техник обработки больших данных. В этой статье я расскажу про проект Oxide — одну из наших ключевых инициатив прошлого года по переписыванию ядра Trino с Java на Rust.

Если вы настроили многоузловой кластер Kafka, то, вероятно, знаете, что в нем есть части конфигурации, общие для кластера, а есть уникальные для каждого узла.

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

Поменяли на одном брокере — настройки применили везде.

Bourne again shell.

Как мечта гения прошлого века задает тренды нашего столетия

12 января 2026 года исполнилось 119 лет со дня рождения Сергея Павловича Королева. Его нет с нами уже более полувека, но созданный им космический «задел» до сих пор определяет контуры не только российской, но и мировой космонавтики. Мы живем в эпоху Илона Маска и частных стартапов, возвращения на Луну и полетов к Марсу. При чем здесь советский конструктор, родившийся при царе? Ответ прост: именно Королёв заложил фундаментальные принципы, на которых стоит наше сегодняшнее представление о космосе как о пространстве для жизни, работы и мечты.

Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.

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

В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.

После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.