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

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

Мне довелось выступить техническим экспертом на бизнес-акселераторе Genesis: IT & Telecom в СибГУТИ.

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

Декабрь… месяц, когда ощущаешь волшебство везде — в первом снеге, в зимнем какао, в запахе хвои, в разноцветных огоньках гирлянд, в шорохе упаковочной бумаги, в улыбках прохожих. Это пора, когда даже самые серьезные взрослые лиды и синьоры, будто на мгновение превращаются в детей, верящих в чудеса стабильной работы новогодних релизов обновления ИТ‑ландшафта. ИТ‑мир становится волшебнее, а волшебный мир — технологичнее. Мы верим в Деда Мороза и его верных помощников, которые создают новогоднюю сказку, а что если и до волшебного мира добрались инновации? А может Дед Мороз — это самый продвинутый айтишник?

Для организации волшебной сказки для детей и взрослых команда Деда Мороза готовится целый год. Круглый год главный волшебник получает письма с заветными желаниями, к декабрю можно насчитать уже миллиарды запросов на подарки. Наш Дед Мороз «идет в ногу» с современными технологиями, поэтому у него есть секретные ИТ‑системы для автоматизации волшебных процессов, построенных на магическом open source‑коктейле, включающем заморского оленя Рудольфа — Apache NiFi, с отечественными patch‑подковами и упряжкой компонентов ручной работы талантливых мастеров.

Центр управления новогодним волшебством «хо‑хо»

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

Команда Go for Devs подготовила перевод статьи о том, как построить Heavy-Read API на Go, способный обрабатывать более 1 млн запросов в секунду. Автор делится продакшен-архитектурой распределённого In-Memory Cache, показывает, как убрать БД и Redis из критического пути чтения, и объясняет, за счёт каких оптимизаций удаётся добиться субмиллисекундных задержек. Практика, цифры и реальные уроки из продакшена.

Компания Shenzhen Xunlong Software выпустила новую open-source плату на базе 12-ядерного высокопроизводительного процессора Armv9 Cix P1 CD8160. Плата предыдущего поколения Orange PI 5 построена на Rockchip RK3588. Новый процессор Cix P1 состоит из 8 ядер Cortex‑A720 и 4-х Cortex‑A520, и обещает прирост производительности на 300% по сравнению с последним Rockchip RK3588. Ядро Cortex‑A720 было впервые представлено публике в 2023 году и через два года уже готова плата на новых процессорных ядрах. Из коробки работает UEFI/TianoCore EDK II (ED2) с запуском Debian, Android, Windows 11. Под катом разберемся с новой архитектурой Armv9, рассмотрим процессор Cix P1, оценим производительность новой платы и сравним с предыдущим поколением, платой Orange PI 5 Plus.

Отказоустойчивый и масштабируемый энтерпрайз невозможно спроектировать по книжкам. Одно и то же решение может фигурировать и в best, и в bad practice — и, что забавно, иногда переходит из одного списка в другой. Ещё недавно монолиты считались злом, а теперь снова в моде.

Хотите посмотреть, как знакомые паттерны ведут себя в реальном контексте?

Чтобы показать это на практике, я собрала три инженерных кейса. Каждый оформлен в формате детективного квиза: роль, фабула, вопросы на размышление, разбор и выводы. Попробуйте разобраться в проблеме, пройти тест и определить: где костыль, где инженерный компромисс, а где — настоящая best practice.

Вы настроили retention.ms = 86400000 (24 часа) и отправили тестовое сообщение. Через сколько времени реально удалится сообщение?

MASQUE интересен не как «ещё один VPN», а как пример того, куда движется транспортный уровень интернета.

За три недели экспериментальный прототип превратился в полноценную реализацию с тестами, метриками и документацией, делимся результатами.

Привет, Хабр! Меня всё ещё зовут Данила Федюкин, и я продолжаю быть тимлидом в X5 Digital. Руковожу командой, которая занимается метчингом. В прошлый раз я рассказывал, как мы перешли на собственную систему рекомендаций, а в этот раз о том, как делаем то же самое, но с метчингом товаров.

X5 Digital – один из цифровых бизнесов Х5. Мы работаем в режиме Highload с RPS в 7500 и отвечаем за всю онлайн-доставку в более чем 1000 городах и населённых пунктах России.

Этот канал постоянно растёт. В 2024 году покупатели Х5 совершили свыше 119,5 млн заказов продуктов на дом.

Мы делаем собственную in-house WMS для дарксторов, приложения для сборщиков и курьеров, CRM, каталоги товаров и другие онлайн-продукты, а ещё мобильное приложение для торговых сетей.

Всё это, отталкиваясь от разных форматов доставки. В «Перекрёстке» среднее время доставки CTD (Click-to-Delivery — от оформления заказа до его получения клиентом) сократилось до 45 минут, в «Чижике» — до 37 минут, а в «Пятёрочке» порядка 40% заказов доставляются клиентам менее чем за 20 минут.

Сегодня разберёмся с Bulkhead-паттерном в коде .NET. Bulkhead, своего рода защитная клетка для ваших ресурсов. Суть в том, чтобы изолировать группы запросов или операций так, чтобы отказ или перегрузка в одной ячейке не утопила всю систему. Без разделения лёгкий запрос может ждать, пока тратится весь пул потоков тяжёлой задачей.

Благодаря Bulkhead каждый поток или потребитель получает выделенный пул ресурсов и может работать даже при сбое или загрузке других. Это помогает предотвратить большое и ненужное расходование ресурсов, если один сервис начинает есть всё CPU или соединения, его проблемы останутся в его же сегменте.

В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.

ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом -  «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя.

Если вы когда-либо строили высоконагруженные системы поиска, то знаете, что в какой-то момент узким местом становится не код, а сама архитектура. Поиск доступных отелей — как раз тот случай: миллиарды «ночей», десятки тысяч RPS, постоянные обновления календарей, строгая консистентность и высокая цена любой ошибки. Старый стек на Python + Postgres + Redis долго тянул, но однажды стал «тормозить» настолько, что оптимизировать дальше было невозможно — SQL-запросы разрастались, реплики множились, latency прыгала до 60 секунд, а кэширование превращалось в источник инцидентов.

Так мы пришли к идее построить собственную in-memory базу данных на Go — заточенную под наш домен. Быструю, безопасную и синхронизированную с Postgres. 

Под катом — история того, как мы её спроектировали, какие архитектурные решения приняли, как победили холодный старт, справились с миллиардами значений. И почему в итоге смогли полностью отказаться от кэша доступности, переведя поиск в real‑time.

В этой статье мы поделимся некоторыми подробностями работы над новыми функциями Greengage, такими как shrink и expand кластера, улучшение вставки для foreign-таблиц и подготовка к интеграции с Apache Iceberg.

У вас есть запрос к базе данных или к платному API, и вы кэшируете результат? Для кэша используете ConcurrentDictionary или MemoryCache?

У кэша, построенного на этих классах, есть одна неприятная проблема: отсутствие защиты от давки кэша (cache stampede). При определённой нагрузке кэш будет многократно выполнять один и тот же запрос из-за отсутствия координации между потоками и репликами. В этой статье я наглядно покажу, как давка кэша влияет на C# приложение и что с этим делать.

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.

Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.

Ранее мы рассматривали различные варианты балансировки нагрузки (HTTP, L4) с помощью Angie. Однако мы обходили стороной вопрос отказоустойчивости. Балансировщик становится единой точкой отказа для системы, и эту проблему необходимо решать. Одним из решений является использование протокола VRRP для организации отказоустойчивого кластера — его мы и разберём в этой статье.

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

Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.

Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.

Всем привет! Меня зовут Андрей, с Банки.ру я связан уже больше 14 лет, а сейчас руковожу командой Платформы и забочусь о гильдии девопсов.

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

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

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

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

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

В статье не будет технических деталей, будут даны только принципиально важные детали реализации и критически важные параметры.