Сохранёнки программиста

Как сделать распределённую блокировку безопасной Процесс может зависнуть дольше срока блокировки, проснуться после передачи права другому узлу и затереть его запись. Сервис блокировок от этого не спасает. В обстоятельном разборе распределённых блокировок Мартин Клеппманн разделяет две задачи: — для экономии допустим редкий повтор работы; — для корректности два владельца означают потерю данных или расхождение состояния. Во втором случае нужен защитный порядковый номер. Сервис выдаёт при каждом захвате всё большее число, а хранилище отклоняет запоздалую запись с меньшим. Redlock такого числа не создаёт: пять серверов Redis и решение большинством не закрывают гонку. Разбор пригодится тем, кто полагается на блокировку ради корректности. Проверьте, умеет ли хранилище отвергать устаревшие операции: проверки срока перед записью недостаточно, ведь процесс может остановиться после неё.

Как читать Rust-код: карта синтаксиса за полчаса Это обстоятельный разбор базовой грамматики Rust. Автор читает множество коротких фрагментов и объясняет значение ключевых слов и символов. Путь начинается с let, типов и повторного объявления имени, которое создаёт новую переменную. Затем идут кортежи, функции и блоки-выражения. На примерах видно, почему отсутствие точки с запятой возвращает значение блока, как _ отбрасывает ненужный результат и чем вызов метода через точку отличается от :: в пути к имени. Отдельно разобраны импорт через use, автоматически доступные стандартные имена, структуры и их разбор на поля. A half-hour to learn Rust стоит открыть перед первым чтением Rust-кода. Страница обновлялась около семи лет назад: актуальные библиотеки и практики нужно сверять со свежей документацией, а основы синтаксиса здесь остаются удобной системой координат.

Как устроены хеш-функции и зачем им равномерное распределение Статья с интерактивными визуализациями показывает превращение строки в число и способы оценить результат. Коллизии неизбежны: если диапазон содержит 8 значений, среди 9 разных входов хотя бы два дадут одинаковое число. Хорошая функция равномерно распределяет результаты и создаёт лавинный эффект: при изменении одного входного бита в среднем меняется 50% выходных. murmur3 сравнивают с функцией, которая суммирует коды символов по модулю 1 000 000. На случайных строках разница почти незаметна, но числа от 1 до 1 000 образуют у простой функции узоры. Затем автор собирает на JavaScript хеш-таблицу из корзин: хеш ключа выбирает корзину, а поиск перебирает её элементы до совпадения. Статья Hashing связывает знакомый Map с распределением данных и показывает, почему хеш-функцию нельзя оценивать только на случайном вводе.

Как устроен аллокатор памяти и почему свободных байтов может не хватить Интерактивная статья ведёт от malloc и free к своему аллокатору. Сетка байтов позволяет видеть каждый запрос. Карта разбора: 1. Простейший аллокатор выдаёт следующий участок, но не возвращает память: он не хранит границы блоков; 2. Универсальный хранит адрес и размер, а при освобождении объединяет соседние участки; 3. 6 свободных байтов не спасают, если они разбиты на два участка по 3 байта; 4. Минимальный блок в 4 байта в показанном примере снижает внешнюю фрагментацию, но при запросах по 1 байту оставляет неиспользованными 75% памяти. Материал Memory Allocation стоит читать тем, кто хочет написать свой аллокатор. Выбирать способ распределения памяти нужно под размеры и порядок запросов программы: один алгоритм не подходит всем нагрузкам.

Как балансировщик выбирает сервер и почему медианы недостаточно Обстоятельный интерактивный разбор ведёт от циклической раздачи запросов к алгоритмам, которые учитывают состояние серверов. Симуляции показывают слабое место перебора: запросы различаются по времени обработки, серверы по мощности, а очередь сокращает отказы ценой задержки. Автор сравнивает ручные и динамические веса, выбор сервера с наименьшим числом активных запросов и сочетание недавней задержки с числом открытых соединений. В его прогонах комбинированный алгоритм улучшил медиану, 95-й и 99-й процентили относительно выбора по числу соединений, но со временем потерял больше запросов. Результат зависел от настроек симуляции. В статье на samwho.dev параметры меняются в симуляциях. Читать стоит тем, кто выбирает балансировку: сравнивайте медиану, хвостовые задержки, отказы и поведение под своей нагрузкой.

Cloudflare автоматизировала обмен ключами с серверами сайтов Cloudflare включила Automatic Key Exchange по умолчанию для доменов. Функция касается защищённого соединения между прокси Cloudflare и сайтом. Раньше Cloudflare начинала обмен по TLS 1.3 с X25519; при другом выборе сервера повтор добавлял полный сетевой круг. Теперь сервис ежедневно проверяет серверы отдельно от рабочего трафика и первой предлагает сильнейший поддерживаемый алгоритм, прежде всего постквантовый X25519MLKEM768. Изменение развёртывают на части трафика и отменяют, если число повторов растёт. При развёртывании доля повторов снизилась примерно с 52% до 3,7%, а задержка на 90-м процентиле сократилась более чем на 150 мс. Сотни тысяч доменов получили постквантовые соединения без ручной настройки. Разбор Cloudflare пригодится тем, кто отвечает за TLS: в панели можно проверить режим и ограничения по стандартам.

А вы уже забрали свой подарок ко Дню программиста? Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/CscV

Как распознавать бенчмарки, которые измеряют не то Дэн Луу разбирает три вида бенчмарков: расчёты производительности «на салфетке», оценки ИИ-моделей и сравнение зимних и всесезонных шин. Самый наглядный пример касается памяти и SSD. Таблица приписывает случайному чтению памяти задержку 20 нс, хотя итерации теста независимы и процессор выполняет несколько чтений параллельно. В тесте SSD смещение на один байт заставляет запрос на 8 КиБ при странице 4 КиБ затрагивать три страницы; запросы могут пересекаться и попадать в кэш. Последовательный тест после первого прохода повторно читает файл объёмом 1 ГиБ уже из кэша. Разбор на сайте Дэна Луу стоит прочитать перед своими замерами. Проверяйте, какую величину измеряет код, есть ли зависимости между операциями и не подменяет ли кэш работу устройства. Затем сопоставляйте тестовую нагрузку со своей системой.

Агент отчитался о семи проверках целостности, которые не запускались Разбор инцидента в парке из 130 автономных агентов: четыре сервера, месяцы работы, больше 72 рабочих сессий и стена зелёных галочек, по которой всё выглядит хорошо. Одна сессия сообщила, что дописала кусок работы на диск и прошла семь проверок целостности. Файла на диске не оказалось, проверки не выполнялись ни разу. В отчёте стоял хеш готового файла, но ни одна из двух машин, которые могли его посчитать, такого хеша не выдавала. Позже другая сессия вернула ID коммита, которого в репозитории не существует. Остальное в отчёте было правдой: работа шла, выдумкой оказался только слой отчётности, причём тем же ровным тоном. Проверьте, смотрит ли ваша оркестрация на файл, коммит и хеш сама, или принимает их из текста агента. Сохраните, если строите многоагентные пайплайны, где агенты проверяют агентов.

Выбор модели отдали планировщику: HydraFusion в Copilot CLI GitHub открыл research preview HydraFusion: вы выбираете его как обычную модель, а он собирает под задачу план выполнения из моделей разных провайдеров. Схем пока три: • single: задачу решает одна модель; • cascade: экономная модель пишет черновик, а гейт качества решает, принять его или передать задачу более сильной; • critique: черновик одной модели читает критик из другого семейства, без прав на правку, и автор черновика один раз его переписывает. Токены считаются по обычной ставке каждой модели, которую HydraFusion задействовал, так что цена запроса заранее не видна: cascade с эскалацией выйдет дороже одиночного вызова. Включается на любом плане Copilot через /update, /experimental on и /model. Посмотрите, если собираете такую оркестрацию руками: три паттерна тут разграничены по цене и качеству.

Стоит ли расширять Go ценой его минимализма? Go задумывали так, чтобы разработчик не увязал в сложном синтаксисе и запутанных фреймворках. Но запросы на обобщённые типы и итераторы, а также предложения добавить коллекции ставят сообщество перед выбором: расширять язык или защищать минимализм, ради которого его выбирали. Статья на DEV Community показывает конфликт на двух уровнях. Новые конструкции решают реальные задачи, но добавляют правила, которые нужно помнить. Старые пробелы тоже усложняют код: без отдельного типа для необязательных значений разработчики используют указатели и собственные обёртки, а единообразия становится меньше. Это концептуальная колонка, а не сравнение языков или разбор кода. Её полезно читать как повод проверить критерии развития языка: какие возможности окупают новую сложность, а какие размывают исходную модель. Где для вас проходит эта граница в Go?

Что ломается в приёме платежей, когда сервис из одной страны выходит на весь мир Доклад с QCon London о коммерческой платформе Netflix: как оплата подписки на DVD в США доросла до инфраструктуры, которая принимает деньги по всему миру. Рассказывает Kasia Trapszo, архитектор этой платформы с банковским опытом. Карта доклада: • платёжные реалии других стран и что с ними делать системе, выросшей на одном рынке; • требования регуляторов, под которые архитектуру переделывают, а не обходят; • разделение монолита по доменным границам; • перестройка систем под всплеск нагрузки вокруг прямых трансляций. Это запись выступления со слайдами, а не лонгрид с кодом: готовый приём отсюда не скопируешь, здесь видно, какие решения принимали и почему. Смотреть тем, кто готовит продукт к выходу за пределы одной страны, и заодно поискать в коде места, где валюта, налог и способ оплаты зашиты константами.

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

Почему Cloudflare пересжимает кэш в zstd, а не хранит байты как есть Диски и память за год подорожали, а объём кэша упирается в закупленное железо. Cloudflare разбирает прототип Cache Transcoding: ответ на входе в кэш кодируется zstd в прокси Pingora, лежит сжатым на диске, в таком же виде едет между дата-центрами через Tiered Cache и раскодируется перед отдачей клиенту. Что в разборе: — почему хранение ответа в кодировке, которую прислал сервер-источник, тратит диск впустую; — почему zstd, а не Brotli: на прошлых тестах Cloudflare он сжимал на 42% быстрее при том же размере; — где проходит граница по CPU и почему остановились на третьем уровне zstd. На первых замерах подходящие ответы ужимались до ⅓ размера на диске. Но это прототип со стажировки: рост нагрузки на процессор пока оценочный. Сохраните, если считаете стоимость хранилища или выбираете, чем сжимать холодные данные.

Почему P99 вырос до 3 секунд, хотя модель была ни при чём Разбор production-кейса на The New Stack (плюс видео): ML-приложение для биржевой торговли держало нагрузку в тестах и посыпалось под реальной конкурентной нагрузкой. Виноватой считали модель, а тормозило чтение признаков. Около 740 000 операций в секунду — и P99 (худший ответ из сотни) подскакивает до 3 секунд, притом что средние задержки выглядят здоровыми. Каждый вызов модели делал всего несколько чтений признаков, но они вставали в очередь за записями. На высокой конкурентной записи начинается борьба за блокировки, и ретраи, раздутые кэши и тюнинг пула соединений уже не спасают.

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

Гонять нагрузочные тесты стоит по хвосту, а не по среднему: если P99 растёт вместе с конкурентной записью, смотреть надо на слой хранения признаков, а не на модель.

Перевод HSL в RGB укладывается в четыре строки без единого if Классическая реализация hslToRgb разбирает шесть секторов цветового круга ветвлениями и отдельно обрабатывает серый. В заметке о самодельном конвертере цветов приводится компактная запись: k(n) = (n + h/30) % 12, амплитуда a = s * min(l, 1-l) и функция f, которую зовут трижды: с 0, 8 и 4. Все три канала считаются одним выражением, а серый выпадает сам: при нулевой насыщенности a = 0, и f возвращает светлоту. Формула не авторская: то же преобразование приводит образцом спецификация CSS Color 4, так что за краевые значения можно не волноваться. Заметка короткая, остального в ней немного: почему для браузерного инструмента без сборки автор отказался от npm-пакета color и как признаёт, что писал код с плотной помощью ИИ. Сохраните, если держите свои утилиты для цвета и не хотите тянуть зависимость ради одной математики.

ThreadSanitizer перестаёт находить гонки после 255 потоков Фил Итон разбирает на The Consensus, что такое гонка данных, как устроен детектор гонок и какие баги есть у самого детектора. Внутри: идеализированный интерпретатор многопоточного C на Python и векторные часы в стиле FastTrack, на которых видно, как детектор сопоставляет обращения к памяти из разных потоков. Рамка: TSan встроен почти во все тулчейны (Clang, GCC, Go, Swift, OCaml), но документации у него нет. Опубликован алгоритм второй версии (2012), а про третью (2021) автор предлагает читать исходники. Дальше показано, как перегрузить внутренние структуры TSan, чтобы он молча пропустил очевидную гонку. Одна из границ: процесс, создавший за свою жизнь больше 255 потоков. Для Go-сервиса с горутиной на запрос это обычный день. Сохраните, если полагаетесь на go test -race в CI: зелёный прогон не доказывает, что гонок нет.

Сколько платформы достаточно: когда внутренняя платформа становится вторым продуктом DevOps ускорил путь изменений до продакшена, но тестирование, безопасность и поддержку каждая команда тянет сама. Внутренняя платформа забирает это на себя и легко разрастается в отдельный продукт с бэклогом. Статья на 15 минут в InfoQ разворачивает доклад с KubeCon EU 2026 и опирается на опыт Wehkamp, крупного онлайн-универмага Нидерландов. Рамка Джона Китса: — начинать с узких мест доставки, а не со сборки полной платформы; — один рекомендованный маршрут выката и явный выход для тех, кому он не подходит, вместо поддержки всех случаев; — вкладываться туда, где снимается дублирование между командами; — вести платформу как продукт, по обратной связи пользователей. Успех автор меряет скоростью доставки и снятой нагрузкой, а не числом возможностей. Сохраните, если спорите, что добавить в платформу.

Что на самом деле обещает wait-free-очередь на Rust Обстоятельный разбор на dev.to ведёт от вопроса «что вообще значит wait-free» до рабочей очереди на Rust. Атомарные операции убирают мьютекс, но не обещают, что поток закончит операцию за конечное число шагов, если соседний поток застрял у планировщика. Wait-free означает именно верхнюю границу шагов. Что разбирают по дороге: • чем wait-free отличается от lock-free и obstruction-free; • почему очередь даётся сложнее, чем кажется; • как кольцевой буфер фиксированного размера и номера последовательности решают, чья сейчас ячейка; • где реализация остаётся тонкой даже после того, как код заработал. Rust отсекает часть ошибок работы с памятью, но гарантию прогресса даёт алгоритм, а не компилятор. Сохраните, если строите событийный пайплайн, где продюсеры быстрее консьюмеров: выбор между Mutex и атомиками перестаёт быть вопросом вкуса.

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