Высоконагруженные системы *

Привет, Хабр! Меня зовут Алексей, я архитектор в команде Скала^р (входим в Группу Rubytech).
Мы разрабатываем программно-аппаратные комплексы (ПАК) — для баз данных, динамической инфраструктуры, интеллектуального хранения данных, больших данных и отраслевых задач в госсекторе, финансах и промышленности. В этой статье — про один из самых молодых, но самых турбулентных классов ПАК в нашем портфеле: инфраструктуру под ИИ-задачи, на примере «Машины искусственного интеллекта Скала^р (Скала^р МИИ)».

Формат статьи немного нетипичный для обзора продукта. Я не буду перечислять фичи по порядку — вместо этого попробую показать путь типового заказчика: с какими проблемами он сталкивается не на этапе закупки, а через два-три месяца эксплуатации, когда стенд уже работает, деньги потрачены, а перформанс почему-то не тот, что ожидался. И сразу — что мы сделали в ПАК, чтобы заказчик в принципе не попадал в эту точку.

Бывают ошибки, которые не видит ни ревью, ни тесты: код отрабатывает правильно, прогон зелёный, а запросов к базе он делает в сто раз больше прежнего. Я убрал из фонового планировщика классический N+1 — самым что ни на есть учебным способом — и чуть не выкатил в прод версию, где нагрузка росла как квадрат числа пользователей. Разбираемся с замерами в руках: при чём тут expire_on_commit, почему предзагрузка пачкой сама по себе ни в чём не виновата и как одна строка превращает цикл в N².

Микросервисы обещают независимость и гибкость, но вместе с этим добавляют новый класс проблем: задержки между сервисами, каскадные сбои и сложность управления зависимостями.

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

Продолжаем классифицировать ошибки, с которыми сталкивается пользователь при работе в 1С.

Сегодня – блокировки. Это, наверное, самый распространенный пласт ошибок. С точки зрения пользователя платформа 1С сообщает ему что-то маловразумительное про какие-то там конфликты блокировок, возможно, с набором каких-то символов. И после этого его операция прерывается...

Разбираемся как увидеть, разобраться и побороть.

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

Но вот какова правда: для корректной работы продьюсеров в событийно-ориентированной системе не обязательно упорядочивать события. Действительно не обойтись без свойств, обеспечивающих правильный контекст — такой информации, как номера версий, метки времени updatedAt и идентификаторы объектов, по которой потребители могут самостоятельно судить о свежести и согласованности событий.

Это разбор архитектуры системы управления транспортом — без сроков, без смет и без сравнения технологий по галочкам. Только устройство: из чего система собрана, как разложена по кластеру, куда идут данные и почему именно так.

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

Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, PostgreSQL, Redis из шести.

Docker для userver удобен, но не обязателен. Как поставить зависимости через apt, собрать сервис нативно на Ubuntu и не утонуть в первой компиляции.

Сразу отвечаю на вопрос, который вы задали бы в первом же комментарии: а почему не pgvector?

Короткий ответ: ровно то, что pgvector делает хорошо — генерацию кандидатов (найти top‑k ближайших по косинусу) — мы и советуем отдавать pgvector, если он у вас есть. Свой ANN мы написали, потому что (1) pgvector есть не везде, где должна работать наша память, и (2) самое ценное в нашей задаче — вообще не генерация кандидатов. Про это вся статья, так что давайте по порядку.

Вопрос производительности работы сервера Angie и различных оптимизаций не раз поднимался в других статьях цикла. Поэтому здесь мы соберём основные приёмы и подходы к настройке Angie для высоких нагрузок, а за подробностями по отдельным вопросам будем направлять читателя в специализированные статьи.

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

Курс «HighLoad тестирование для 1С и корпоративных систем: полный курс» посвящен всему циклу нагрузочного тестирования: от анализа исходной системы и проектирования сценария до запуска тестов, интерпретации результатов и подготовки рекомендаций...

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

Признавайтесь: вы пользуетесь std::collections::HashMap примерно каждый день и ни разу не задумывались, что под ним. А под ним, если коротко, сидит алгоритм от Google. С Rust 1.36 (это лето 2019-го) стандартный HashMap это порт SwissTable, той самой структуры из абсейловского flat_hash_map. До этого там был Robin Hood hashing, и если вы где-то ещё видите описание std-мапы как «linear probing and Robin Hood bucket stealing», знайте: оно протухло, актуальная документация уже пишет «quadratic probing and SIMD lookup».

И вот «SIMD lookup» это самое интересное. Весь фокус скорости SwissTable держится на одном байте служебных данных на элемент, который сканируется по 16 штук за одну инструкцию процессора.

В статье глянем, как это устроено внутри, почему ваша мапа по умолчанию устойчива к hash DoS и платит за это скоростью, когда в проде стоит переходить на FxHash, и почему низкоуровневый RawTable существует, но в публичном HashMap его спрятали.

Будет много кода и немного ассемблерной романтики.

Привет! Я Саша Рыжов, MLOps-инженер в hh.ru, уже три года занимаюсь развитием инфраструктуры для искусственного интеллекта. Компании, которые развивают GenAI, рано или поздно приходят к задачам по запуску LLM на собственном железе. В статье я расскажу, как обстоят дела с движками инференса в 2026 году и как запустить on‑prem-прод и не изобрести при этом велосипед.

Отмена задачи кажется простой, пока сервис не зависает при остановке, таймаут не оставляет запрос работать в фоне, а CancelledError исчезает внутри обработчика исключений. Разберём, как устроена кооперативная отмена в asyncio, где ставить точки ожидания и как использовать TaskGroup, timeout и shield, чтобы задачи завершались предсказуемо.

Пять пробелов, которые не видны на архитектурных блок-схемах.

Пользователь нажимает «Place Order» (Сделать заказ).

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

А потом в службу поддержки прилетает тикет.

Представим обычную обработку заказа. Сервис заказов публикует событие order.created. Сервис склада получает его и резервирует товар в PostgreSQL. После успешной транзакции обработчик должен отправить RabbitMQ подтверждение (Ack), чтобы broker удалил сообщение из queue.

Но процесс может остановиться после записи в PostgreSQL и до отправки Ack. RabbitMQ не знает, успел ли сервис зарезервировать товар. Broker видит только неподтверждённое сообщение, поэтому доставляет его ещё раз. С точки зрения доставки это правильное поведение. С точки зрения бизнеса один заказ теперь может зарезервировать товар дважды.

Другой сбой возникает раньше: PostgreSQL временно недоступен, и обработчик не может начать работу. Если сразу вернуть сообщение в queue через отрицательное подтверждение Nack(requeue=true), RabbitMQ почти немедленно доставит его снова. Пока база не восстановилась, все попытки будут бесполезными. Нужны задержка и ограничение числа повторов. При этом отложенное сообщение может пропустить вперёд более новые события, поэтому отдельно придётся решить вопрос порядка.

Так одна операция превращается в несколько независимых участков: запись события, публикация, хранение в broker, обработка и подтверждение. Между соседними участками остаются моменты, когда одна сторона уже выполнила действие, а другая ещё не получила подтверждение.

В статье разберём эти моменты по всему пути сообщения. Затем построим практическую схему для RabbitMQ и Go: добавим ограниченные повторы через retry queues, время жизни сообщения (TTL) и dead letter exchange, сделаем обработчик идемпотентным и определим, куда отправлять сообщения, которые не удалось обработать автоматически. В конце сравним этот подход с Kafka, NATS JetStream и Amazon SQS.

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.

Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

Если вы работаете с системами для управления корпоративным контентом, то понимаете, что главная их проблема — это недостаточный уровень производительности. То, что прекрасно работает на 20 документах, тормозит и выдает ошибки на 2 млн. Как узнать об этой проблеме до того, как система сдана клиенту в промышленную эксплуатацию? Ответ: провести нагрузочное тестирование.

Привет! Мы — Владимир Семенов, старший системный архитектор LDM (входит в холдинг LANSOFT), и Олеся Панкова, инженер по нагрузочному тестированию. В нашей статье — не сухие цифры из отчета, а экспертиза инженеров команды.

Мой мемный сервис «Шакализатор» победил в премии Яндекс Практикума, но меня больше интересовал другой вопрос: как VPS с одним ядром и 1 ГБ RAM пережил 1,2 млн запросов за сутки?

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