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

Сколько сообщений в секунду выдерживает MQTT‑брокер? Без описания нагрузки этот вопрос почти ничего не говорит. Приём сообщений от множества устройств, доставка одного сообщения тысяче подписчиков и обслуживание сотен тысяч соединений нагружают сервер по‑разному.

Я сравнил Mosquitto, EMQX, FlashMQ, HiveMQ Community Edition и XMQ на одном AWS‑стенде. Меня интересовали доставленная скорость, задержка и потребление CPU и памяти, а также то, что происходит, когда брокер не успевает за заданной нагрузкой.

Сразу обозначу свою заинтересованность: я разработчик XMQ. Генератор нагрузки xmq_scn также входит в этот проект. Поэтому рядом с результатами нужны версии, сценарии, конфигурации и исходные отчёты: читатель должен иметь возможность проверить эксперимент.

Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента».

И сразу, пока вы не пролистали до конца, вопрос к вам.

Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого‑то ваш комментарий станет поводом проверить свой план до аварии, а не после.

А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.

Привет!

В стандартной библиотеке лежит макрос pin!. Стабильный с версии 1.68, живёт в core, зовёт его каждый, кто хоть раз закреплял футуру на стеке. Значащая для нашего разговора строчка внутри у него одна, и повторить её у себя не выйдет: конструкции, на которой она держится, в языке официально нет.

Случай не единственный, второй лежит вообще на виду. Откройте объявление Vec и посмотрите внимательно: там не Vec<T>, а Vec<T, A = Global>, два параметра. Попробуйте назвать второй своими руками, и на пять строк кода прилетят три ошибки, потому что Global нестабилен.

Прикол в том, что на фичах, которых в стабильном Rust как бы нет, держится куча всего, чем мы пользуемся каждый день. В первой части так вышло с gen-блоками, pattern types, специализацией, become и #[loop_match]. Сегодня разберёмся, зачем pin! выписал себе особый пропуск. Почему второй параметр Vec сидит под замком дольше всех остальных. Как компилятор посчитает вашу корзину до копейки ещё до запуска программы. Что лежит внутри толстого указателя, если раскрутить его на запчасти. И почему SIMD руками обгоняет автовекторизацию только до того момента, пока вы не разрешите компилятору лишнего.

Ты не владеешь источником — значит, не владеешь временем. Как поллер по updated_at молча теряет строки, почему exactly-once это свойство твоей записи, и почему сверка важнее потока.

Когда LLM помещается на одной GPU и получает несколько запросов в минуту, настройка движка инференса обычно заканчивается на выборе модели и типа данных. Проблемы начинаются дальше: модель перестает помещаться в память, растет очередь запросов, длинные промпты съедают KV-кэш, а GPU простаивают в ожидании обмена данными друг с другом. 

В этой статье я помогу тем, кто только погружается в мир LLM-инференса, разобраться во всем многообразии настроек одного из самых популярных фреймворков инференса - SGLang.

Разберем пять групп настроек: параллелизм: TP, DP, CP, PP и EP, KV-кэш: Radix Cache и HiCache, вычисления и коммуникации в MoE, attention-бекенд, спекулятивное декодирование. Задача — не перечислить все CLI-флаги SGLang, а понять, что именно в пайплайне инференса меняет каждая настройка и в какой ситуации ее имеет смысл трогать. Поехали! 

Обновили Go до 1.25 и оставили привычный automaxprocs? Пустой импорт теперь может отключить встроенное управление GOMAXPROCS и изменить поведение сервиса под CPU‑квотой. Разбираемся, как новый рантайм работает с cgroup, откуда берётся разница на дробных лимитах и что проверить перед удалением старой зависимости.

Битовые массивы кажутся экзотической структурой данных, которую применяют только опытные учёные мужи в специфичных сферах? Не всегда!

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

Под катом — эволюция от классических битовых массивов до современных сжатых форматов и реальный бизнес‑кейс их прикладного применения.

Знакомая картина: в 3 часа ночи падает база данных, Alertmanager засыпает каналами, через 5 минут сеть восстанавливается, но… система остаётся «мёртвой». CPU на воркерах 100 %, Goodput на нуле, а перезапуск подов только усугубляет ситуацию. Все указывает на то, что вы столкнулись с метастабильным отказом — самым коварным типом аварий в распределённых системах.

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

Когда говорят о PL/I, воображение часто рисует большие машины и программы из другой эпохи. Но у языка есть и вполне современная сторона: процедуры, массивы, многопоточное выполнение. Если вы писали на Go или Python, базовый сценарий будет понятен: запустить работу в фоне, пока она идёт заняться чем‑то ещё, а затем дождаться результата.

Разберём этот сценарий на примерах, которые опираются на реализованную многозадачность в pli‑llvm — новом открытом кроссплатформенном компиляторе языка PL/I, который был создан на основе спецификации языка TR25 с добавлением некоторых более поздних полезных фишек из IBM Enterprise PL/I.

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

Система прошла функциональные проверки: документы проводятся, отчёты формируются, интеграции работают. Но после подключения нескольких сотен пользователей операции замедляются, а серверы оказываются перегружены. Чтобы разобраться в причинах, нужно связать прикладную логику, поведение СУБД и состояние инфраструктуры. Нагрузочное тестирование помогает специалисту 1С расширить свою ответственность — от проверки отдельных сценариев до оценки готовности системы к промышленной эксплуатации.

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

С комментариями Гейдара Габриэлянца, автора и преподавателя курса «HighLoad-тестирование для 1С и корпоративных систем», разбираем, какие компетенции для этого понадобятся и как меняются задачи по мере профессионального роста.

C++ умеет ровно то, за что его одновременно любят и боятся: дает разработчику почти полный контроль над происходящим, позволяет выжимать из программы максимум производительности, но при этом оставляет возможность столкнуться с ошибкой, которая проявится только через несколько часов или даже дней работы. На C++ строят высоконагруженные системы, движки, embedded-решения и инфраструктуру, хотя рядом уже много лет развиваются Go, Rust и другие языки, которые обещают сделать разработку проще и безопаснее.

Так зачем учить C++ в 2026 году? Насколько важно программисту разбираться в памяти и устройстве процессора? Почему сильных C++-разработчиков по-прежнему мало, хотя язык преподают в университетах? Где без C++ действительно сложно обойтись, а где бизнесу выгоднее выбрать Go и при необходимости добавить серверов? Сможет ли Rust потеснить C++, как нейросети меняют работу программиста и почему современному разработчику уже недостаточно просто знать синтаксис?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Малковым — C++-разработчиком, бывшим сотрудником Яндекса и CTO компании «Вертикаль». Александр также ведет свой телеграм-канал «Thread of Thoughts | Поток мыслей», где делится материалами и наблюдениями из профессиональной практики.  

Разговор получился не только про сам C++, но и про то, что сегодня требуется от сильного разработчика. Мы обсудили userver и падения продакшена, высокие нагрузки и работу с памятью, HFT и геймдев, компиляторы и санитайзеры, работу с legacy-кодом, а также влияние ИИ на профессию. Поговорили о нейросетях в роли своеобразного «джуна на ревью», выгорании в Big Tech и о том, в каких задачах глубокое понимание устройства системы по-прежнему важнее знания конкретного языка.

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

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

С новым обновленным изданием книги вы сможете разобраться в терминологии и решить какой вариант лучше всего подойдет для вашего приложения.

Если вы когда‑либо строили пайплайны для обработки потоков данных в реальном времени со строгими требованиями, то наверняка знаете, сколько инфраструктурных заморочек в этом деле. Например, обеспечивать относительно низкие end‑to‑end‑задержки в штатном режиме относительно несложно. Но что, если они нужны и в высоких перцентилях, в том числе при сбоях или плановом обслуживании одного из используемых дата‑центров целиком? Как правильно партиционировать поток данных, обрабатывающие его процессы и их долгосрочное состояние, если нагрузка постоянно меняется? Как гарантировать exactly‑once, то есть отсутствие потерь и дублей даже при сбоях оборудования и в краевых случаях? Как понять, обработали ли мы все данные на тот или иной момент? 

С такими вопросами мы столкнулись при разработке высоконагруженных рекомендательных систем. Для этих задач мы создали YTsaurus Flow — фреймворк потоковой обработки данных с сохранением состояния между событиями и гарантиями exactly‑once по умолчанию. Это совместный проект команд Yandex Infrastructure и Яндекс Рекламы для обработки потоков данных в реальном времени. И сегодня мы открываем его исходный код под лицензией Apache® 2.0.

Flow — часть YTsaurus, платформы хранения и обработки данных, которую мы выложили на GitHub в марте 2023 года. Flow использует хранилище, очереди и общий механизм транзакций платформы, чтобы брать на себя управление состоянием и восстановление обработки после сбоев. Разработчик пайплайна при этом сосредоточивается на прикладной логике.

В статье разберём, зачем мы разработали собственный движок, как устроены его пайплайны и за счёт чего обеспечивается exactly‑once. А на примере реального сервиса покажем, как переход на Flow помог сократить задержку поставки данных для дообучения моделей с десятка‑другого часов примерно до двух.

YOLO обрабатывает кадр дольше, чем камера формирует следующий. Если построить видеосервер как последовательность read → motion → YOLO → encode, тяжёлая модель остановит чтение RTSP, очередь начнёт расти, а пользователь увидит прошлое вместо прямого эфира.

В статье разбираю real‑time‑конвейер своего C++20-сервера: постоянные workers, слоты последнего значения, std::jthread, stop_token, защита от устаревших результатов и итоги 16-часового теста на реальной RTSP‑камере.

Всем привет. На днях попалась информация интересная и захотелось разобраться в сервисе, которым пользуются миллионы людей – это Spotify.

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

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

Давайте разберёмся.

Несколько лет назад мы решили заменить legacy e‑commerce‑платформу, которая продолжала работать и принимать заказы. Новый frontend построили на Next.js, backend — на Symfony, перед ними поставили Nginx. Но после запуска выяснилось, что самое интересное только начинается.

В статье разберу реальную production‑архитектуру: SSR, восемь процессов Next.js, несколько уровней кэширования, интеграции с внешними системами и проблемы актуальности данных. А главное — какие решения спустя несколько лет эксплуатации я бы спроектировал иначе.

Всем привет! Нет, я не навайбкодил очередную обёртку над OpenRouter и не буду продавать её в этой статье. Повод не случайный: очередная массовая волна банов от Anthropic — на этот раз банят даже давно живущие, трастовые личные аккаунты.

Кто я: Лёша Жиряков, амбассадор агентной AI-разработки, веду воркшопы, делюсь опытом. Меня на них часто спрашивают, на чём жить, если основные инструменты отвалились. Код писать надо вчера, а что вообще пускает с российского IP, толком никто не знал. Я взял curl и прошёлся по 25 сервисам.

TL;DR: с домашнего IP, без VPN и прокси, по 25 сервисам: живых 9 (OpenCode, Qwen, Z.ai, DeepSeek, MiniMax, Mistral, Kimi, Zed, Trae), не пускают 15. Замер: 1 октября 2026.

Рейт-лимит — это не ограничение скорости. Это бюджет, и тратишь его не ты один. Разбор на Telegram Bot API, Redis и одном наивном планировщике 2023 года.