Как контролировать целостность данных

~ 45 минут
Целостность данных — это фундаментальный аспект безопасности и надёжности информационных систем. Отсутствие контроля целостности может привести к утрате или искажению данных. Это поставит под угрозу как бизнес-процессы, так и безопасность пользователей.
Угрожать целостности данных могут как внешние угрозы (например, атаки хакеров), так и ошибки в работе самой системы. В этом уроке мы сосредоточимся на втором сценарии.
Вы уже знаете, что в распределённых системах сложно обеспечить целостность данных. Микросервисная архитектура распределяет работу между множеством отдельных сервисов, которые могут находиться на разных узлах системы и взаимодействовать друг с другом по сети. В таких условиях каждая операция, которая затрагивает несколько сервисов, может привести к проблемам с синхронизацией данных.
Сейчас мы рассмотрим механизмы контроля целостности данных и расскажем, как можно реализовать требования ACID в распределённых системах.

Принципы контроля целостности данных

Целостность данных нарушается, если данные случайно или намеренно изменяются или утрачиваются. Контроль целостности означает, что команда может обеспечить корректность данных на протяжении всего их жизненного цикла. В том числе — в процессе их хранения, передачи и обработки.
Контроль целостности опирается на требования ACID — Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция), Durability (устойчивость). Традиционно ACID понимают как набор свойств транзакций в реляционных базах данных. Но мы предлагаем рассматривать их как базовые принципы, которые помогают обеспечить целостность данных в любой информационной системе, независимо от её архитектуры. Этот подход потребует некоторых оговорок, потому что в распределённых системах требования ACID понимаются и реализуются немного иначе.
В распределённых системах и микросервисной архитектуре ACID сложно реализовать напрямую. Традиционные инструменты здесь не работают, потому что микросервисы, как правило, используют независимые базы данных и выполняют операции асинхронно.
Например, в классической архитектуре транзакция может затрагивать несколько таблиц одной базы данных. В этом случае требования ACID обеспечиваются на уровне этой БД. А в микросервисной архитектуре каждая операция может затрагивать разные сервисы с отдельными базами данных.

Напомним, что тут может пойти не так

  • Данные могут временно находиться в несогласованном состоянии, если разные сервисы обрабатывают одну и ту же информацию с задержкой.
  • Сетевые сбои или отказ одного из сервисов могут нарушить целостность данных, поскольку невозможно гарантировать успешное завершение всех операций одновременно.
  • Каждый микросервис может использовать собственную базу данных или механизм хранения. Это усложняет координацию данных между ними.
Чтобы гарантировать ACID для операций в распределённой среде, нужно использовать дополнительные механизмы. К ним относятся двухфазный коммит, компенсационные транзакции и ещё несколько паттернов.
Чтобы было проще разобраться в этих подходах и проследить их связь с ACID, мы будем разбирать их на примере компании PropVisor.

Кейс компании PropVisor

Стартап PropVisor занимается автоматизированной оценкой земельных участков и недвижимости, основанной на алгоритмах машинного обучения. Чтобы сформировать максимально точные отчёты о состоянии и стоимости объектов недвижимости, система PropVisor анализирует данные аэрофотосъёмки и спутниковых снимков.
Оценка стоимости включает не только базовые характеристики недвижимости, но и такие факторы, как:
  • близость к школам, магазинам и другим объектам городской инфраструктуры,
  • наличие красивого вида,
  • уровень шума (близость к автомагистралям, аэропортам и так далее),
  • экологическую обстановку.
Обеспечение целостности и достоверности данных — ключевая задача компании. Иначе она не сможет гарантировать клиентам, что её оценка стоимости справедливая и актуальная.
Теперь перейдём к механизмам для обеспечения ACID. Первый метод, который мы рассмотрим, — это двухфазный коммит.

Двухфазный коммит

Протокол двухфазного коммита (2PC) используют, когда транзакция затрагивает несколько узлов или сервисов. Протокол гарантирует, что либо все изменения будут зафиксированы одновременно, либо все изменения откатятся.
Таким образом, двухфазный коммит позволяет реализовать в распределённых системах два первых принципа ACID:
  • атомарность — транзакция либо успешна, либо откатывается.
  • согласованность — данные остаются в корректном состоянии.
Протокол состоит из двух фаз. Рассмотрим их по порядку.

Фаза 1. Подготовка — Prepare Phase

На этом этапе координатор отправляет запрос на все узлы (сервисы), которые участвуют в транзакции. Запрос содержит вопрос «Готовы ли вы зафиксировать транзакцию?». Каждый узел проверяет, может ли он выполнить изменения, и отвечает координатору.
Обратите внимание: в рамках этой фазы узлы готовятся к фиксации данных, но они не будут её выполнять, пока не получат окончательное подтверждение от координатора.

Фаза 2. Фиксация или откат — Commit or Abort Phase

Здесь координатор принимает решение о проведении транзакции на основе ответов, которые он получил на прошлой фазе.
Если все узлы согласились зафиксировать изменения, координатор отправляет команду commit и все участники фиксируют свои изменения, завершая транзакцию. Если хотя бы один из узлов не готов, координатор отправляет команду abort и все изменения откатываются, возвращая данные в исходное состояние.
Важно понимать, что двухфазный коммит блокирует ресурсы до тех пор, пока транзакция не завершится или не откатится. Таким образом механизм обеспечивает атомарность транзакций. Но такой подход может создать проблемы с производительностью.
На схеме вы видите две ноды БД. Мы изобразили самый простой сценарий, чтобы наглядно показать главный принцип. В реальности здесь могут быть, например, шесть хранилищ разного типа данных. В этом случае влияние на производительность будет значительным.
У двухфазного коммита есть ещё несколько недостатков, о которых важно знать.

Минусы двухфазного коммита

  • Во время выполнения двухфазного коммита ресурсы остаются заблокированными, что может влиять на производительность.
  • Участники связаны между собой и каждый из них должен взаимодействовать с координатором. Это создаёт тесную зависимость между компонентами.
  • Если координатор или участник «зависнет» или выйдет из строя, процесс коммита тоже может зависнуть. Это приведёт к блокировке всей транзакции.
Эти недостатки могут помешать реализации остальных принципов ACID — изолированности и устойчивости. Из-за этих особенностей двухфазный коммит крайне редко используют в микросервисной архитектуре. Вместо него обычно применяют паттерн Saga или асинхронное согласование.

Когда использовать двухфазный коммит

Двухфазный коммит можно было бы отнести к антипаттернам микросервисной архитектуры, если бы не одно но. Этот механизм полезен и даже незаменим в ряде ситуаций. Его используют, если:
  • Нужна строгая согласованность данных. Согласно теореме CAP, в реализации распределённых вычислений невозможно одновременно обеспечить согласованность (Consistency), доступность (Availability) и устойчивость к разделению сети (Partition Tolerance). Можно выбрать только два свойства из трёх. Если в приоритете у компании согласованность и устойчивость, то двухфазный коммит — это хорошее решение. Примером такого бизнес-запроса могут служить банковские транзакции. В этом случае ожидание завершения коммита оправдано.
  • Невозможно использовать компенсирующие транзакции. Здесь в качестве примера можно привести платёжные операции, в которых после перевода невозможен откат-компенсация.

Кейс компании PropVisor

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

Сергей

Какие есть альтернативы?

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

Eventual Consistency

В распределённых системах важно понять и принять, что не все данные должны быть немедленно согласованы между всеми узлами хранения. Достаточно, чтобы это произошло со временем.
В качестве примера возьмём социальные сети: когда вы публикуете пост, он сразу же становится видимым для вас и ваших друзей. Но в некоторых случаях другие пользователи могут увидеть его с небольшой задержкой. Это происходит из-за того, что данные о вашем посте распространяются серверам системы. Через некоторое время пост будет доступен всем, но моментальная синхронизация в этом случае не требуется.
В этом нам помогает Eventual Consistency — фундаментальная концепция, которая позволяет системе продолжать работать, не дожидаясь синхронизации всех данных между нодами.
✏️ Eventual Consistency, или согласованность в конечном итоге, — это модель согласованности, при которой гарантируется, что, если новых обновлений данных не происходит, все копии данных на узлах системы со временем придут к одному и тому же состоянию.
В отличие от строгой согласованности (Strong Consistency), которую требует традиционная модель ACID, согласованность в конечном итоге не обеспечивает мгновенную консистентность данных после каждого обновления. Зато эта модель позволяет системе работать более гибко и эффективно, особенно в условиях высокой нагрузки или сетевых сбоев.
Если обратиться к требованиям ACID, то Eventual Consistency обеспечивает требования согласованности и устойчивости, но с определёнными упрощениями:
  • Согласованность. Система не гарантирует, что данные будут согласованными в каждый момент времени, но обещает, что все узлы со временем придут к одному и тому же состоянию.
  • Устойчивость. Данные сохраняются и распространяются по системе даже после сбоя.

Когда использовать Eventual Consistency

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

Как реализовать Eventual Consistency

Чтобы реализовать согласованность в конечном итоге, потребуется комплекс мер. Для этого нужно:
  1. Внедрить асинхронную репликацию. Это основа Eventual Consistency. При этом подходе данные обновляются асинхронно на разных узлах. Каждый узел обрабатывает свою часть операции независимо. Система достигает согласованного состояния после завершения всех операций.
  2. Выбрать и внедрить механизм отслеживания изменений (Change Data Capture). Используйте журналы транзакций или отслеживание изменений на уровне базы данных, чтобы зафиксировать изменения данных и распространить их на другие сервисы.
  3. Продумать идентификацию конфликтов. Если возникнет конфликт между несколькими изменениями, можно применить правила разрешения конфликтов. Например, «последний записанный побеждает» (Last Write Wins) или использовать контрольные суммы.

Подробнее о принципе Last Write Wins

Принцип «последний записанный побеждает» (Last Write Wins, LWW) — это один из наиболее простых и распространённых подходов к разрешению конфликтов в распределённых системах, где различные узлы одновременно изменяют одни и те же данные. Суть метода заключается в том, что система сравнивает версии данных по времени изменения и считает актуальной последнюю версию.
Предположим, возник конфликт: два узла одновременно пытаются обновить одни и те же данные. Чтобы определить, какое изменение произошло последним, система использует метки времени — timestamps. Данные с более поздней меткой времени замещают предыдущие данные, и все узлы приводятся в соответствие с этим последним изменением. Это помогает системе поддерживать согласованность и избавляет от необходимости сохранять все конфликтующие версии данных.
Пример. Два узла одновременно обновляют цену объекта недвижимости. Первый узел изменяет цену с 500 000 на 520 000, а второй узел — с 500 000 на 510 000. Поскольку оба изменения происходят одновременно, возникает конфликт. Система сравнивает временные метки этих изменений. Обновление от первого узла пришло с более поздней меткой времени, поэтому система сохранит значение 520 000, а изменение со значением 510 000 проигнорирует.
Ограничения
Метод LWW прост и эффективен, но всё же имеет недостатки. Этот подход не учитывает семантику данных: он полагается только на время и проигнорирует более раннее изменение, даже если оно важнее с точки зрения бизнеса. Если обновление с более поздней меткой времени перезапишет критически важную информацию, это может привести к потере важных данных.
Таким образом, LWW удобен для систем с высокой частотой обновлений, где критично минимизировать задержки и количество конфликтов. Однако он может не подойти для систем, где важен контекст изменения данных и нужна более сложная логика разрешения конфликтов.

Кейс компании PropVisor

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

Компенсационные транзакции в микросервисах

В распределённых системах управление транзакциями обычно реализуют с помощью паттерна Saga. Он позволяет компенсировать отсутствие двухфазного коммита.
Саги помогают реализовать принципы атомарности и согласованности ACID, хоть и не в классическом виде:
  • Атомарность. В традиционной модели ACID система должна дождаться выполнения всех шагов транзакции. А компенсирующие транзакции в микросервисной архитектуре в случае ошибки откатывают действия на любом этапе. Это гарантирует атомарность: если что-то пошло не так, система возвращается в исходное состояние, отменяя все операции.
  • Согласованность. В результате применения компенсирующих операций данные остаются в корректном и согласованном состоянии.
🔍 Более подробно паттерн Saga мы рассматривали в первом спринте (урок «Паттерн Saga») и в третьем спринте (урок «Ключевые паттерны микросервисного приложения»). Если хотите повторить материал, можете вернуться в эти уроки.

Кейс компании PropVisor

Процесс оценки недвижимости в PropVisor затрагивает три сервиса:
  • сервис анализа спутниковых снимков,
  • сервис сравнения данных с кадастровыми записями,
  • сервис расчёта рыночной стоимости.
Компания решила внедрить Saga для управления транзакциями. Допустим, один из сервисов не может завершить операцию — например, сервер спутниковых данных временно недоступен. В этом случае система автоматически запускает компенсирующие действия, чтобы откатить все связанные операции и вернуть систему в согласованное состояние.
Такой подход позволяет PropVisor:
  • избежать блокировок, которые часто возникают при централизованной координации транзакций;
  • поддерживать высокую отказоустойчивость всей системы, гарантируя непрерывность работы даже в условиях сбоев.

Приёмы, которые компенсируют отсутствие транзакций в распределённых системах

В условиях микросервисной архитектуры отсутствие централизованных транзакций накладывает ограничения на контроль целостности. Однако существует ряд приёмов, которые позволяют это компенсировать. К ним относятся Event Sourcing и CQRS. Эти подходы не исключают использование саг, а дополняют их и друг друга.

Event Sourcing

🔍 Про паттерн Event Sourcing в курсе был отдельный урок — «Работа с данными в event-driven архитектурах».
Кратко напомним основную идею: этот подход предполагает, что изменения данных сохраняются в виде последовательности событий. Это позволяет восстановить состояние системы в любой момент времени. При сбое или откате можно просто «проиграть» последовательность событий заново.
Event Sourcing, с одной стороны, решает проблему логов, а с другой стороны — вообще не стремится к мгновенной согласованности.
Кейс компании PropVisor
Допустим, PropVisor хранит итоговую оценку стоимости объекта недвижимости. Вместо этого можно хранить каждое событие, которое привело к изменению этой оценки.
Тогда каждое изменение рыночной стоимости, обновление данных о кадастровой записи или изменение экологической обстановки фиксируется как отдельное событие. Эти события накапливаются в журнале событий (event log). А текущее состояние оценки недвижимости вычисляется через последовательное проигрывание всех событий, связанных с данным объектом.
Предположим, что изначально стоимость дома оценивалась в 3 миллиона рублей. После этого произошла такая последовательность событий:
  1. Изменение кадастровой стоимости объекта: +200 000 рублей.
  2. Обновление рыночной стоимости по региону: +150 000 рублей.
  3. Изменение экологической ситуации в районе: -50 000 рублей.
Когда клиент запрашивает текущую оценку стоимости объекта, система просто воспроизводит все эти события и рассчитывает итоговую стоимость: 3 000 000 + 200 000 + 150 000 - 50 000 = 3 300 000 рублей.
Если на каком-то этапе произойдёт ошибка (например, сбой в получении новых данных о рынке), то PropVisor сможет откатить изменения, просто исключив последнее событие из списка, и пересчитать результат на основе исправленных данных.

CQRS

🔍 Более подробно паттерн CQRS мы рассматривали в уроке «Ключевые паттерны микросервисного приложения».
Напомним основную идею: CQRS предполагает разделение операций чтения и записи. Команды (операции записи) могут быть асинхронными и возвращать немедленный ответ, в то время как операции чтения обращаются к специально подготовленным представлениям данных. Это снижает нагрузку на систему и повышает устойчивость к сбоям.
Кейс компании PropVisor
PropVisor использует различные источники данных для оценки недвижимости, такие как спутниковые снимки и кадастровые данные. Эти данные могут поступать с задержками или асинхронно. Чтобы обеспечить высокую производительность и масштабируемость, компания может разделить операции на запросы и команды:
  1. Команды (Commands). Когда пользователь запрашивает оценку недвижимости, система отправляет команду для запуска процесса оценки. Данные обновляются асинхронно: система начинает собирать информацию из спутниковых данных, кадастра, рыночных показателей. Как только процесс завершён, результат сохраняется. При этом пользователю можно сразу отправить уведомление, что его запрос принят и находится в обработке.
  2. Запросы (Queries). Когда пользователь хочет посмотреть историю оценок или запросить текущую стоимость объекта, система направляет запросы к специальной базе данных или кеш-системе, где уже подготовлены итоговые данные для быстрого доступа. Запросы на чтение направляются в специализированное хранилище, не влияя на операции записи.
Когда PropVisor получает новые спутниковые снимки, они отправляются в систему для обновления данных. Процесс записи занимает время, но пользователи могут в любой момент обратиться к текущей оценке недвижимости через кешированные представления. Это позволяет системе оставаться гибкой и масштабируемой, снижая нагрузку на основные процессы обработки данных.
Подведём итоги для кейса. Архитектура PropVisor выигрывает от использования этих двух паттернов:
  • Event Sourcing позволяет отслеживать каждое изменение стоимости недвижимости, что даёт возможность вернуться к любой версии оценки, анализировать причины изменений или восстанавливать состояние при сбоях.
  • CQRS снижает нагрузку на систему при большом количестве запросов на оценку недвижимости, позволяя быстро отвечать пользователям за счёт разделения операций на запись и чтение.
Выполните несколько заданий, чтобы закрепить материал. А потом — подведём итоги урока.

Задание 1

Компания QuickSell разрабатывает приложение маркетплейса. Разработчики используют микросервисную архитектуру: за оформление заказа отвечает один сервис, а за оплату — другой. Команда решила отказаться от двухфазного коммита, чтобы обеспечить высокую производительность приложения.
Какие подходы компания может использовать, чтобы обеспечить согласованность данных между сервисами и компенсировать отсутствие двухфазного коммита?

Задание 2

Компания QuickSell реализовала Event Sourcing. Какую задачу помогает решить этот подход в условиях микросервисной архитектуры?

Что почитать о контроле целостности данных?

Итоги

  • Чтобы гарантировать безопасность системы, нужно контролировать целостность данных. К нарушению целостности данных могут привести как атаки хакеров, так и несовершенства самой системы. В распределённых системах контролировать целостность данных сложно — эту задачу необходимо решать на этапе проектирования.
  • Контроль целостности данных опирается на требования ACID. Их можно рассматривать как базовые принципы, которые помогают обеспечить целостность данных в любой информационной системе, независимо от её архитектуры.
  • Чтобы гарантировать ACID для операций в распределённой среде, нужно использовать дополнительные механизмы. К ним относятся двухфазный коммит, принцип согласованности в конечном итоге, паттерн Saga, Even Sourcing и CQRS.
  • Двухфазный коммит гарантирует атомарность и согласованность операций. Он состоит из двух фаз: подготовки (Prepare Phase) и коммита или отката (Commit or Abort Phase). В рамках первой фазы координатор отправляет запрос на все узлы (сервисы), которые участвуют в транзакции, чтобы они подтвердили свою готовность к комиту. В рамках второй фазы координатор принимает решение о проведении транзакции. Если хотя бы один из узлов не может зафиксировать изменения, координатор отправляет команду abort и все изменения откатываются. У этого подхода много недостатков: двухфазный коммит блокирует ресурсы на период проведения транзакции, компоненты зависят друг от друга и от координатора, а отказ одного узла может привести к блокировке всей транзакции. Из-за этого двухфазный коммит используют редко.
  • Паттерн Saga — это альтернатива двухфазному коммиту. Этот подход также гарантирует атомарность и согласованность операций, но уже за счёт компенсационных транзакций. Саги опираются на концепцию Eventual Consistency, которая предполагает иной подход к согласованности данных. Согласно Eventual Consistency, данные могут какое-то время находиться в несогласованном состоянии, но система должна гарантировать, что со временем они придут к общему состоянию.
  • Паттерны Even Sourcing и CQRS можно применять вместе с сагами. Они позволяют компенсировать отсутствие централизованных транзакций и повысить устойчивость системы к сбоям.
В следующем уроке мы расскажем про атаки на целостность данных и обсудим стратегии защиты.