Транзакции: сессии и атомарность

Сессия в mongo-driver — клиентский объект, который группирует операции и держит серверный контекст исполнения; без неё транзакций не бывает вовсе. В v2 основной вход — метод client.UseSession(ctx, fn): драйвер создаёт сессию, прикрепляет её к контексту и вызывает ваш колбэк, а по выходу из колбэка закрывает сессию сам. Подпись колбэка честная: fn получает обычный context.Context — отдельного типа SessionContext, знакомого по статьям про первую версию драйвера, в v2 больше нет. Сессия достаётся из контекста функцией mongo.SessionFromContext(ctx), которая вернёт *Session или nil вне сессионного контекста. Старый путь с ручным управлением тоже легален: client.StartSession() без колбэка возвращает сессию напрямую, и тогда EndSession зовёте сами через defer — UseSession просто оборачивает эту связку в удобную обёртку. Драйвер предупреждает прямо в документации: контекст колбэка не потокобезопасен, и пользоваться им из нескольких горутин нельзя. Практическое следствие простое: на один HTTP-запрос — одна сессия, и все операции запроса исполняются через её контекст. За неявным закрытием прячется полезная работа: EndSession при выходе сначала откатит оставшуюся незакоммиченной транзакцию через AbortTransaction и лишь потом закроет сессию — серверные ресурсы не текут. Если сессии нужны нестандартные уровни чтения и записи по умолчанию, у UseSession есть старший брат UseSessionWithOptions: он принимает конструктор options.Session() с дефолтными ReadConcern, WriteConcern и ReadPreference, а транзакция при старте вправе переопределить их своими опциями.

Транзакция настраивается конструктором options.Transaction(): SetWriteConcern, SetReadConcern и SetReadPreference — три доступных ручки, и их хватает. Канон, который рекомендует документация MongoDB: WriteConcern majority — запись подтверждается большинством узлов реплики, ReadConcern snapshot — операции внутри видят согласованный снимок данных на момент старта. Пакеты mongo/writeconcern и mongo/readconcern дают готовые значения: writeconcern.Majority() и readconcern.Snapshot() — связка из двух строк в конструкторе. Сами уровни не уникальны для транзакций — их же ставят обычным Find и UpdateOne через опции коллекции; внутри транзакции они просто важнее вдвойне, потому что защищают не один запрос, а всю группу. Почему именно snapshot: внутри транзакции вы читаете текущий баланс и тут же пишете новый; без изоляции снимка между этими двумя шагами вклинится чужая запись, и вся атомарность станет декорацией. С snapshot драйвер читает то же состояние, на которое опирается запись, — либо обе операции легли согласованно, либо конфликт откатил всё вместе. Опции передаются аргументом в StartTransaction и действуют на всю транзакцию целиком. Для типового сервиса их достаточно объявить один раз пакетной константой и переиспользовать в каждом переводе. ReadPreference пригодится в геораспределённых кластерах, где чтение хочется вести с ближайшего узла; в обычном develop-кластере из одного узла это уже тонкость, о которой можно не вспоминать.

Транзакция завершается одним из двух способов: CommitTransaction(ctx) фиксирует все изменения разом, AbortTransaction(ctx) откатывает. Коммит — обычная операция с ошибкой в возвращаемом значении: пробросить её наружу через fmt.Errorf с контекстом — обязанность вашего кода, драйвер сам никуда её не положит. Явный Abort уместен при понятной ошибке приложения: счёт заблокирован, лимит превышен, проверка не прошла. Третий путь, о котором часто забывают: если из колбэка UseSession выйти, а коммит не сделан, EndSession вызовет AbortTransaction сам — незакоммиченные изменения исчезнут без следа. Это удобно, но коварно: забытый коммит выглядит как код, который отработал и ничего не сделал, и ищут такой дефект по странному поведению данных, а не по ошибкам. В v2 автоматики в другую сторону нет: сам драйвер коммитит только по вашей команде, автоматически работает лишь откат. Отдельная история — повторы. Retryable writes, которые молча перечитывают одиночную запись при сетевой осечке, на транзакцию как целое не распространяются; вместо этого драйвер предлагает WithTransaction, повторяющий весь колбэк по меткам ошибок, — о нём дальше. И нюанс коммита: если CommitTransaction упал с сетевой ошибкой, судьба изменений остаётся неизвестной — повторный коммит безопасен, а вот AbortTransaction после неудачного коммита драйвер прямо называет опасным шагом, потому что откат может исполниться параллельно с фактически прошедшим коммитом на другом узле.

Две границы сервера стоит знать до прода, а не после инцидента. Первая — время: транзакция по умолчанию живёт 60 секунд, параметр transactionLifetimeLimitSeconds, после чего сервер убивает её сам, и колбэк получает ошибку. Порог поднимается администратором на сервере, но строить архитектуру на этой ручке — плохая идея: длинные транзакции дольше держат серверные блокировки и мешают всем остальным процессам. Значит, внутри транзакции не место внешним HTTP-вызовам, тяжёлым расчётам и ожиданию ввода пользователя: транзакция — короткая атомарная запись, а не обёртка для бизнес-процесса. Вторая граница — размер: весь набор изменений транзакции ложится в одну oplog-запись с общим лимитом 16 МБ; транзакция, меняющая сотни тысяч крупных документов, упрётся в потолок и упадёт на коммите со странной на первый взгляд ошибкой. Требование к топологии то же, что и при отладке: транзакции исполняют replica set и шардированный кластер, где mongos проксирует их на шарды; одиночный mongod отклоняет операцию сразу. Отсюда прикладное правило: транзакция должна закрывать маленькую согласованную запись — пару коллекций и десяток операций. Если атомарности требует большой объём, данные моделируют иначе — встраивают, денормализуют, режут на этапы, — а не растягивают транзакцию до предела.

Транзакции — тяжёлая артиллерия, и чаще всего она стреляет мимо цели. Запись одного документа в MongoDB атомарна сама по себе: UpdateOne с $inc и Upsert из десятого урока закрывают счётчики, лимиты и синхронизацию без всяких сессий и опций. Если логика меняет одну коллекцию, поместите данные в один документ — встроенный subdocument обновляется атомарно, и разводить поля по коллекциям ради красивой схемы не нужно. Многодокументная транзакция оправдана, когда согласованность между разными коллекциями обязательна и обойти её нельзя: деньги, остатки на складе, квоты и дедупликация по двум хранилищам. А если реакция на изменение не обязана быть мгновенно согласованной, очередь или подписка на события дешевле и живучее — об этом девятнадцатый урок. Слой репозитория двадцать первого урока здесь не посторонний гость: методы репозитория принимают context.Context, поэтому сессионный контекст протекает внутрь без переделок, и транзакция оборачивает вызовы репозитория, а не дублирует их SQL-подобным кодом. Прежде чем писать UseSession, честно ответьте: действительно ли двум записям нужно умирать и оживать вместе. Дешёвая проверка перед транзакцией: попробуйте закрыть задачу одним документом со вложенными полями — в документной базе это чаще всего и есть правильное моделирование, а не уродливый компромисс.