Как‑то раз мне пришлось переносить с монолитного легаси в новенький микросервис интеграцию с платежным провайдером.
Изучив старый код, я понял, что так дело не пойдет. Два клика по «Оплатить» — два запроса в провайдер. Два Check — два финансовых документа по одной оплате. Два Cancel — два Reverse. В монолите это еще как‑то жило, а в микросервисе, который запускается в двух репликах, локальный SemaphoreSlim вообще перестал что‑либо гарантировать.
Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.
Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.
В нашей базе данных существует таблица events. Данные в неё постоянно дописываются и располагаются в инкрементируемых event_block. В одном event_blockЧитать полностью »
В PostgreSQL существует очень удобный механизм рекомендательных блокировок, они же — advisory locks. Мы в «Тензоре» используем их во многих местах системы, но мало кто детально понимает, как конкретно они работают, и какие проблемы можно получить при неправильном обращении.
