Как заказ переживает сбой: транзакции, реплики и восстановление

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

Четыре свойства ACID отвечают на разные вопросы. Атомарность — какие изменения принимаются вместе; согласованность — какие правила состояния сохраняются; изоляция — как взаимодействуют параллельные операции; долговечность — какие отказы переживает подтверждённый результат.

База не угадывает правила продажи. Ограничения и логика операции должны выражать нужное правило: обязательность номера заказа, допустимое количество, связь с покупателем. Транзакция может надёжно сохранить ошибку, если заданные проверки её пропускают.

В PostgreSQL CHECK положительности суммы не запрещает NULL: логическое условие считается выполненным и при неизвестном результате. Если сумма обязательна, задайте также NOT NULL. Успешная проверка отрицательного числа ещё не проверяет отсутствие значения.

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

Атомарность транзакции не означает одну машинную инструкцию или отсутствие промежуточной работы. Важен наблюдаемый итог внутри её границы. Разделите испытание отката, конкурентного заказа, отказа оборудования и восстановления до ошибки: один успех не подтверждает остальные свойства.

COMMIT завершает транзакцию фиксацией. Но ответ клиенту может потеряться уже после этого. Таймаут соединения не доказывает откат: нужно выяснить результат конкретной деловой операции или использовать предусмотренный безопасный повтор.

Идемпотентность относится к предполагаемому эффекту повторов. Повторное удаление одного и того же ресурса может вернуть другой статус ответа, хотя требуемое состояние «ресурса нет» осталось тем же. Разные ответы сами по себе не доказывают повторное деловое действие.

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

Отсутствие заказа в отстающей реплике не доказывает, что COMMIT основной базы не состоялся. До решения о повторе выясните, какой источник способен показать результат этой операции. Иначе проверка через устаревшую копию сама станет причиной второго заказа.

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

Грязное чтение использует ещё не зафиксированное изменение другой транзакции. Если та откатится, решение уже опиралось на несуществующий итог. В PostgreSQL 18 режим Read Uncommitted работает как Read Committed и такого чтения не разрешает.

В PostgreSQL Read Committed два обычных SELECT могут видеть разные зафиксированные версии одной строки: каждый получает новый снимок. Это неповторяемое чтение. Если по прежнему условию появился новый набор подходящих строк, речь о фантомном чтении.

MVCC позволяет запросу читать подходящие версии строк. Обычное чтение не обязано ждать каждую конкурентную запись, но явные блокировки и операции изменения структуры имеют отдельные правила. Само наличие MVCC не выбирает за приложение нужный уровень изоляции.

Снимок транзакции задаёт видимость данных, а не сохраняет резервную копию. В PostgreSQL Read Committed снимок относится к команде, Repeatable Read — к транзакции; важен момент получения снимка. Собственные изменения транзакции рассматриваются отдельно от видимости чужих фиксаций.

В PostgreSQL Repeatable Read один BEGIN ещё не фиксирует снимок читаемых данных. Он появляется при первой команде, не управляющей самой транзакцией. Фиксация другого сеанса между BEGIN и первым чтением может попасть в этот снимок; последующие чужие фиксации уже не делают старый снимок свежим.

Отсутствие фантомов не равно сериализуемости. PostgreSQL Repeatable Read сохраняет снимок и не показывает новые чужие строки внутри транзакции, но совместный итог нескольких транзакций ещё может нарушить правило, которое ни одна из них не нарушала в одиночку.

При одном исходном состоянии две транзакции могут каждая разрешить заказ на 70 и вставить разные строки. Общая сумма станет 140 при пределе 100. Если выполнять те же проверки последовательно, второй заказ не прошёл бы: это пример аномалии сериализации, а не грязного чтения.

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

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

Для одного существующего остатка отдельным решением может быть условное уменьшение самой строки. В PostgreSQL Read Committed UPDATE после ожидания конкурента повторно проверяет условие на новой версии строки. Приложение должно учесть ноль изменённых строк; этот приём не доказывает правило по сумме разных заказов.

Линеаризуемость отдельных операций объекта и сериализуемость многооперационных транзакций сравнивают с учётом их границ. Первая связывает операцию с реальным порядком вызовов и ответов; вторая — совместный эффект транзакций с последовательным исполнением. Название одного свойства не доказывает другое для всей заявки.

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

WAL записывает сведения об изменениях до соответствующих страниц данных. При восстановлении после аварии PostgreSQL может воспроизвести необходимую работу по журналу. Подтверждение транзакции поэтому не требует немедленно переписать каждую изменённую страницу на её основное место.

Долговечность проверяют для заданного отказа и настроек подтверждения. Успешный ответ базы нельзя отделять от режима сброса журнала и способности тракта хранения выполнять обещание устойчивой записи. Локальный ответ не описывает автоматически сохранность на другой машине.

В PostgreSQL отключение ожидания синхронной фиксации и отключение fsync меняют разные условия. При synchronous_commit=off последние подтверждённые транзакции могут потеряться после аварии; fsync управляет требованием устойчивого сброса. Не переносите результат проверки одной настройки на другую.

Долговечность принятого текущего состояния и возврат к прошлому состоянию — разные требования. Надёжно записанный ошибочный заказ тоже переживёт перезапуск. Для возврата до ошибки нужны сохранённые материалы и проверенная процедура восстановления.

Сравнивайте результаты испытаний с точной границей: потеря процесса базы, авария ОС, потеря питания, утрата накопителя или площадки. Название WAL само не доказывает, что одна локальная копия покрывает все эти события.

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

Слово «синхронная» требует уточнить выбранный этап. В PostgreSQL remote_write ждёт записи на стороне реплики, но не гарантирует сохранение её буферов после аварии ОС. Ожидание устойчивого сброса и remote_apply задают более поздние точки; последняя включает применение изменений.

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

Удалённое ожидание добавляет зависимость от связи и выбранной реплики. Размещение влияет и на задержку, и на общие отказы. Проверяйте точный состав подтверждения вместе с площадками; количество серверов само не доказывает независимость их питания и сети.

remote_apply подтверждает применение, но не обновляет уже открытый старый снимок читателя. После подтверждения проверяйте чтение с подходящей видимостью. Старая транзакция Repeatable Read может продолжить видеть прежний остаток без нового отставания применения.

Прогресс репликации измеряют по разным этапам: передаче, записи, устойчивому сбросу и применению. Старый результат SELECT может означать задержку применения или старый снимок. Одно число отставания не устанавливает, на каком этапе задержался заказ.

Устойчиво полученный, но ещё не применённый WAL не следует сразу записывать в потерянные данные. Он может позволить довести реплику до более позднего состояния. Для выбранного восстановления отдельно проверьте доступный журнал, его целостность и применимую историю.

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

Поля write_lag, flush_lag и replay_lag PostgreSQL отражают измеренную задержку подтверждения этапов. NULL после периода без активности не является доказательством нулевого отставания. Эти поля также не обещают время, за которое реплика догонит базу после нового всплеска.

Удержание WAL для отставшей реплики расходует место. В PostgreSQL слот репликации помогает сохранить нужную историю, но не создаёт бесконечный накопитель. До длительного отказа реплики проверьте удерживаемый объём, ограничения и порядок восстановления отставшего узла.

В модели Raft узлы согласуют упорядоченный журнал, который затем применяет машина состояний. Голосующее большинство нужно для принятия новых записей по правилам протокола. Речь о модели отказов без произвольного злонамеренного поведения, а не о любом способе распределённого согласования.

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

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

В Raft недостаточно посчитать любые копии записи прежнего срока лидера. Для продвижения фиксации подсчётом реплик действует правило текущего срока; фиксация нужной текущей записи связывает и предшествующий журнал. Номер записи без срока и состояния протокола не доказывает принятое решение.

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

Линеаризуемая операция выглядит совершившейся в одной точке между вызовом и ответом. Если запись уже завершилась до начала чтения и новых записей нет, чтение того же объекта должно учитывать её результат. Одновременно идущие операции допускают порядок в пределах своих перекрывающихся интервалов.

Линеаризуемость отдельных обращений ещё не делает атомарной последовательность «прочитать остаток, проверить, уменьшить». Для общего заказа нужны соответствующие граница и протокол транзакции. Упорядоченный доступ к одной строке и защита всего правила продажи — разные требования.

В модели CAP C означает линеаризуемость; при разделении сети её нельзя гарантировать одновременно с доступностью A. В формальной модели CAP доступность означает, что каждый запрос к неотказавшему узлу в итоге получает ответ. Числового предела задержки это определение не задаёт. Какие ответы допустимы, задаёт спецификация операции: нельзя ни приравнивать формальную доступность к успешной покупке, ни считать произвольную ошибку корректным результатом чтения регистра.

CAP не предлагает постоянно выбирать любые две буквы. PACELC отдельно рассматривает поведение при разделении и обмен задержки на согласованность при обычной связи. Для проекта важны конкретная операция, путь чтения и обязательное удалённое ожидание, а не одна наклейка на продукте.

Если подтверждение новой записи должно дождаться удалённого узла, время доставки запроса и обратного ответа входит в этот путь. Увеличение CPU не устраняет заданную задержку связи. Убирая удалённое ожидание, перепроверьте гарантию этой операции, а не только полученную скорость.

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

У производителя Kafka acks задаёт ожидаемое подтверждение. acks=0 не ждёт ответа брокера; acks=1 ждёт записи в журнал лидера, но не копии у последователей; acks=all ждёт весь текущий ISR — синхронизированные реплики, включая лидера. Для acks=0/1 здесь задан нетранзакционный производитель с enable.idempotence=false. Отказ лидера после acks=1 и до копирования может потерять подтверждённое сообщение. Подтверждение брокера не доказывает платёж.

При acks=all min.insync.replicas задаёт минимум текущего ISR для успешной записи. Если минимум равен двум, одного лидера недостаточно; при текущем ISR из трёх реплик acks=all ждёт все три, а не ровно две. Число назначенных реплик, текущий ISR и минимум — разные величины. При acks=1 этот минимум не превращает ответ лидера в ожидание копий. Подтверждение репликации также не означает обязательный fsync записи на каждом накопителе.

При сохранении позиции до выполнения эффекта сбой может оставить действие невыполненным без повторной обработки. При эффекте до сохранения позиции возникает окно повторного выполнения. Обещание доставки «не менее одного раза» допускает повтор и само не делает внешний платёж однократным.

enable.auto.commit=true включает периодическую фиксацию позиций; auto.commit.interval.ms задаёт интервал, по умолчанию 5000 мс. Если приложение передало платёж отдельному обработчику и продолжает poll, позиция может быть сохранена до эффекта. Проверяйте фактический успешный commit, а не только истечение интервала. enable.auto.commit=false отключает автоматику, но ручной commit до эффекта допускает пропуск, а после эффекта — повтор при сбое между ними. Ни один режим сам не делает оплату атомарной.

Идемпотентный производитель Kafka устраняет определённые дубли отправки в своём протоколе. Он не мешает потребителю второй раз вызвать платёжный API после сбоя. Для внешнего результата нужна защита, охватывающая ту же деловую операцию и её повтор.

В транзакционном пути Kafka выходные записи и позиции потребителя можно фиксировать вместе. Получатели с read_committed не читают отменённые транзакционные записи. Этот охват нужно сохранить в конфигурации и жизненном цикле производителя; произвольная внешняя база или платёж туда автоматически не включается.

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

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

В PostgreSQL подготовленная транзакция может пережить завершение исходного сеанса. Её работа уже завершена до решения COMMIT PREPARED или ROLLBACK PREPARED; продолжить в ней обычные изменения, как в открытом клиентском блоке, нельзя.

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

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

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

Набор материалов зависит от метода. Для PostgreSQL восстановления по архиву WAL нужны подходящая базовая копия и непрерывная необходимая история журнала. Этот способ не является определением всякого восстановления базы; другие методы проверяют по их собственному контракту.

Цель должна предшествовать ошибке, если задача — отменить её результат. Уточните время, транзакцию или позицию и ветвь истории после прежних переключений. Журнал после ошибочного DELETE может честно воспроизвести само удаление; наличие более поздних материалов ещё не выбирает правильную цель.

Запущенный процесс базы не доказывает приёмку. Зафиксируйте использованные материалы, достигнутую точку, фактическое время и результат проверки приложения. Для заказа проверьте состав, остаток и возможность выполнить предусмотренную операцию клиента.

Возврат своей базы не отменяет уже проведённый внешний платёж. Восстановленная позиция обработки может заново выдать старую работу. До возобновления согласуйте деловые операции с сохранившимися внешними результатами; один успешный SQL-запрос не закрывает этот риск.