От чего зависит, будет ли подтверждённая запись сохранена при падении процесса: от синхронной или асинхронной фиксации?
При синхронной фиксации подтверждение отправляют только после достижения заранее выбранной границы надёжности: например, записи в устойчивое хранилище. При асинхронной фиксации ответ может уйти раньше, поэтому падение процесса между подтверждением и фактической записью приводит к потере подтверждённых данных.
Синхронный подход повышает надёжность, но обычно увеличивает задержку записи и снижает её пропускную способность. Асинхронный подход быстрее, однако требует явно принять или компенсировать риск потери данных.
Ранние и распределённые системы часто разделяют приём запроса и его физическую фиксацию: сначала запись попадает в память, очередь или буфер, а затем сохраняется устойчиво. Это позволяет сгладить пики нагрузки и не заставлять клиента ждать медленное хранилище.
Проблема возникла из-за неоднозначного смысла подтверждения. Если ответ означает только «система приняла данные», потеря процесса после ответа может быть допустимой. Если же клиент трактует ответ как «данные не потеряются», подтверждение должно быть связано с устойчивой фиксацией.
Рассмотрим сервис, который получил запись, поместил её в память и сразу ответил клиенту. Если процесс завершится до записи на диск или в другой устойчивый слой, клиент уже считает операцию успешной, но после восстановления данные могут отсутствовать.
Неверный выбор особенно опасен для платежей, заказов, прав доступа и других данных, где повтор операции затруднён. Простое увеличение числа повторных запросов не решает проблему: повтор может создать дубликат, а исходная запись всё равно могла быть частично обработана.
При асинхронной фиксации путь обычно выглядит так: запрос принимается, данные помещаются в буфер, клиент получает ответ, а отдельный процесс позже записывает их устойчиво. Чем дольше интервал между подтверждением и фиксацией, тем больше объём потенциально потерянных данных при сбое.
При синхронной фиксации подтверждение выдают после записи за устойчивую границу. Ею может быть локальный журнал, устойчивый носитель или иной слой, который переживает конкретный рассматриваемый отказ. Важно заранее определить модель отказа: фиксация на одном узле защищает не от тех же событий, что фиксация на нескольких независимых узлах.
Синхронность не означает абсолютную сохранность. Если устойчивое хранилище повреждается, теряется вся площадка или подтверждение выдаётся до реальной фиксации из-за неверной настройки, гарантия оказывается слабее заявленной. Поэтому контракт операции должен явно описывать, что означает успешный ответ и от каких отказов он защищает.
Практический компромисс — разделить классы данных. Критические записи подтверждать после устойчивой фиксации, а некритичные события отправлять асинхронно. Дополнительно применяют идемпотентные идентификаторы операций, контроль очереди и мониторинг отставания фоновой записи, чтобы ограничивать последствия задержек и повторов.
Сервис заказов принимал заказ, сохранял его в памяти и немедленно отвечал клиенту. При перезапуске процесса во время пиковых нагрузок часть подтверждённых заказов исчезала, хотя средняя задержка и доступность API выглядели хорошими.
Рассматривались три варианта. Полностью оставить асинхронную запись было самым быстрым решением, но оно сохраняло риск потери заказов. Сделать синхронной каждую операцию повышало надёжность, однако увеличивало задержку всех запросов и создавало зависимость от производительности хранилища. Отправлять подтверждение после записи в один локальный журнал было дешевле, но не защищало от отказа узла.
Выбрали синхронную фиксацию критической части заказа и асинхронную обработку вторичных событий, таких как уведомления. Успешный ответ выдавался только после записи заказа за устойчивую границу, а фоновые задачи имели идемпотентные ключи. Это устранило потери заказов при перезапуске процесса, сохранив приемлемую задержку для некритичных операций.
Нет. Память процесса обычно теряется при его завершении, поэтому запись в ней не является доказательством устойчивой фиксации. Журнал помогает только тогда, когда он сам записан за требуемую границу надёжности и процедура восстановления действительно умеет воспроизвести его содержимое.
Потому что допустимый риск зависит от бизнес-контракта. Если клиенту явно сообщается, что данные приняты в очередь, а очередь сохраняется устойчиво и имеет ограниченное отставание, потеря может быть исключена или ограничена другим способом. Нельзя считать асинхронность ошибкой без уточнения требуемой семантики подтверждения и модели отказа.
Синхронный путь добавляет зависимость от устойчивого хранилища: его задержка и ошибки становятся частью критического пути. При недоступности этого слоя сервис должен выбирать между отказом операции, чтобы не нарушить гарантию, и подтверждением без фиксации, чтобы сохранить доступность. Правильный выбор определяется приоритетом целостности данных и заранее заявленным SLO.