Транзакции. часть 1. конспект книги «designing data-intensive applications» / хабр

Isolation или изоляция (I)

Переходим к самому интересному свойству — изоляции. Представим ситуацию, когда в определенный момент времени с системой работают несколько пользователей. Естественно, операции транзакции в БД выполняются параллельно, чтобы ускорить работу системы. Но у параллельной работы транзакций есть свои подводные камни:

Если операции транзакции взаимодействуют с разным набором непересекающихся данных, все работает корректно.
Но что будет, если две и более операций транзакции в один момент времени начнут работать с одним и тем же набором данных? Возникнет явление, называемое race condition (состояние гонки).

Выделяют несколько эффектов, связанных с этим явлением.

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

Эффект чтения фантомов возникает, когда набор данных соответствует условиям поиска, но изначально не отображается.

Решение

Для устранения данных эффектов на уровне баз данных предусмотрены уровни изоляции, или transaction isolation levels, которые так или иначе реализованы во многих СУБД. Для примера рассмотрим движок InnoDB в СУБД MySQL:

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

Все запросы SELECT считывают данные в неблокирующей манере.

Блокирующее чтение (SELECT … FOR UPDATE, LOCK IN SHARE MODE), UPDATE и DELETE блокирует искомые индексные строки. Таким образом, возможна вставка данных в промежутки между индексами. Промежутки блокируются только при проверках на дублирующиеся и внешние ключи.

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

Согласованное чтение не накладывает блокировок, однако считывает данные из свежего снэпшота. В остальном ведёт себя так же, как и read uncommitted.

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

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

Блокировка для блокирующего чтения будет зависеть от типа условия:

если условие с диапазоном, например, WHERE (id > 7), то блокируется весь диапазон;
если уникальное, например, WHERE (id = 7), то блокируется одна индексная запись.

Кстати, в InnoDB именно уровень repeatable read используется по умолчанию.

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

Аналогично repeatable read, но есть интересный момент. Если выключен autocommit (а при явном старте транзакции START TRANSACTION он выключен по умолчанию), то все запросы SELECT превращаются в запросы SELECT … LOCK IN SHARE MODE.

SELECT … LOCK IN SHARE MODE – блокирует считываемые строки на запись.

SELECT … FOR UPDATE – блокирует считываемые строки на чтение.

Обоснование транзакционного монитора

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

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

Модель приложения зарезервированных ресурсов

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

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

Эта модель часто предназначена для приложений малого и среднего размера. Две трети архитектурных приложений находятся в этой модели.

Модель приложения общих ресурсов

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

Таким образом, монитор транзакций будет управлять так называемым максимальным количеством транзакций, которые могут выполняться параллельно. Именно это число (а не количество пользователей) определяет характеристики машины. Между каждой транзакцией монитор транзакций не сохраняет в памяти только что завершившуюся пользовательскую транзакцию, так что каждый пользователь ничего не стоит системе после того, как он завершил свою транзакцию.

Сравнение двух моделей

Рассмотрим систему R зарезервированных ресурсов. Для простоты мы скажем, что средняя транзакция T в этой системе потребляет X системных ресурсов во время транзакции T. Если мы хотим, чтобы в этой системе работали 4000 пользователей, мы масштабируем машину до (4000.X) с точки зрения системных ресурсов. .

Теперь рассмотрим систему, оснащенную монитором транзакций M. Мы наложим те же ограничения на 4000 пользователей, желающих выполнять T транзакций, каждый раз потребляя X. Мы оценим, что среднее время транзакции будет 1 с, и предположим, что каждый пользователь будет выполнять в среднем 1 T транзакцию каждые 15 секунд. Таким образом, у нас будет средний трафик 4000/15 = 267 транзакций в секунду, или машина будет иметь размер (267.X) с точки зрения системных ресурсов, или в 15 раз меньше, чем в предыдущей модели.

Недостатки транзакционного монитора

Использование монитора транзакций — один из наиболее структурирующих элементов при разработке компьютерного приложения. Таким образом, мы не можем легко перенести какое-либо приложение на монитор транзакций (в большинстве случаев эти порты даже невозможны и требуют переписывания приложения). Кроме того, программирование в мониторе транзакций накладывает ряд конструктивных и технических ограничений, которые иногда усложняют программирование.

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

Двухфазная фиксация

Распределенные транзакции обычно являются спасением, используемым во множестве случаев:

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

Во всех этих ситуациях, когда масштабируемость не так важна, как согласованность, мы можем рассматривать распределенные транзакции как вариант.

Реализация архитектуры двухфазной фиксации

Технические требования для двухфазной фиксации состоят в том, что вам нужен распределенный менеджер транзакций, такой как Narayana, и надежный уровень хранения для журналов транзакций. Вам также потребуются источники данных, совместимые с DTP XA, с соответствующими драйверами XA, которые могут участвовать в распределенных транзакциях, например RDBMS, брокеры сообщений и кеши. Если вам повезло, что у вас есть нужные источники данных, но вы работаете в динамической среде, такой как Kubernetes , вам также понадобится специальный механизм, чтобы гарантировать наличие только одного экземпляра распределенного диспетчера транзакций. При этом диспетчер транзакций должен быть высоко доступным и всегда иметь доступ к журналу транзакций.

Как пример реализации вы можете использовать на контроллер восстановления Snowdrop, который использует шаблон Kubernetes StatefulSet для гарантии наличия одного элемента и постоянные тома для хранения журналов транзакций. В эту категорию я также включаю такие спецификации, как атомарные транзакции веб-служб (WS-AtomicTransaction) для веб-служб SOAP. Все эти технологии объединяет то, что они реализуют спецификацию XA и имеют центральный координатор транзакций.

В нашем примере, показанном на рисунке 4, служба A использует распределенные транзакции для фиксации всех изменений в своей базе данных и сообщения в очереди, не оставляя никаких шансов дублированию или потере сообщений. Точно так же служба B может использовать распределенные транзакции для приема сообщений и фиксации в базе данных B в одной транзакции без каких-либо дубликатов. Или служба B может решить не использовать распределенные транзакции, а использовать локальные транзакции и реализовать шаблон идемпотентного потребителя. Прошу заметить, подходящим примером для этого раздела было бы использование WS-AtomicTransaction для координации записи в базу данных A и базу данных A в одной транзакции и избежать согласованности в целом. Но в наши дни такой подход встречается еще реже, чем то, что я описал.

Рисунок 4: Двухэтапная фиксация между базой данных и брокером сообщений

Преимущества и недостатки архитектуры двухфазной фиксации

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

В таблице 2 суммированы преимущества и недостатки этого подхода.

Преимущества

Стандартный подход с готовыми менеджерами транзакций и вспомогательными источниками данных.

Сильная согласованность данных для успешных сценариев.

Недостатки

Ограничения масштабируемости.

Возможные сбои восстановления при сбое диспетчера транзакций.

Ограниченная поддержка источников данных.

Требования к хранилищу и наличие единого центрального координатора транзакций в динамических средах.

Примеры

Jakarta Transactions API (ранее Java Transaction API)

WS-AtomicTransaction

JTS/IIOP

eBay GRIT

Atomikos

Narayana

Брокеры сообщений, такие как Apache ActiveMQ

Реляционные источники данных, реализующие спецификацию XA; хранилища данных в памяти, такие как Infinispan

Скользкая концепция транзакции

В конце 2000-х годов приобрели популярность нереляционные (NoSQL) базы данных. Их целью было улучшить существующее положение дел с реляционными БД с помощью новых моделей данных, репликации и секционирования. Транзакции оказались главной жертвой этого новшества: многие базы нового поколения полностью от них отказались или поменяли значение термина: теперь он стал у них означать намного более слабый набор функциональных гарантий, чем ранее.

Вместе с шумихой вокруг этого нового обильного урожая распределенных баз данных стало широко распространяться мнение, что в любой крупномасштабной системе необходимо отказаться от транзакций ради сохранения хорошей производительности и высокой доступности. С другой стороны, производители БД иногда представляют транзакционные функциональные гарантии как обязательное требование для «серьезных приложений», оперирующих «ценными данными». Обе точки зрения — преувеличение.

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

Обеспечиваемые транзакциями гарантии функциональной безопасности часто описываются известной аббревиатурой ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изоляция и сохраняемость).

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

Системы, не соответствующие критериям ACID, иногда называются BASE: «как правило, доступна» (Basically Available), «гибкое состояние» (Soft state) и «конечная согласованность» (Eventual consistency). Это понятие еще более расплывчатое, чем ACID.

Давайте посмотрим на определения атомарности, согласованности, изоляции и сохраняемости. Это позволит уточнить наши представления о транзакции.

Описание

Монитор транзакций — это часть программного обеспечения, часть «промежуточного программного обеспечения», поддерживающая планирование выполнения транзакций и их синхронизацию с целью использования минимально возможных ресурсов в компьютерной системе. В этом случае монитор транзакций — это не механизм управления транзакциями, а скорее «планировщик» ( планировщик ), более или менее сложный, предназначенный для совместного использования ограниченных ресурсов между большим количеством одновременных пользователей, не снижая при этом время отклика компьютерного приложения. .

Исторически потребность в мониторинге транзакций проистекает из того факта, что первые машины ( мэйнфреймы ) имели очень мало ресурсов и что приложения, которые должны были быть развернуты на этих машинах, должны были обслуживать очень большое количество пользователей (авиакомпании, банки, страховые компании, и т. д.). Редакторы того времени, и в основном инженеры IBM, разработали очень мощные системы, чтобы справиться с этой очень высокой транзакционной потребностью с очень ограниченными машинными ресурсами ( в частности, TPF, затем IMS и CICS ).

Durability или долговечность (D)

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

Если вы пользуетесь облачными хранилищами, такими как Amazon S3, то могли заметить, что разные тарифы обещают вам разное количество девяток durability. В контексте облака durability означает сохранность ваших данных и то, как они реплицируются. Чем больше копий ваших данных в разных точках мира, тем выше вероятность их не потерять из-за наводнения, землетрясения или нашествия инопланетян. В контексте «ACID» это обычно означает, что после фиксирования данные записываются в постоянное хранилище.

Свойства транзакции

Выделяют так называемые «магические» свойства транзакции, которые описываются аббревиатурой «ACID». Каждая буква аббревиатуры означает одно из свойств, о которых мы поговорим ниже.

Atomicity или атомарность (A)

Вернемся к предыдущему примеру с переводом денежных средств между двумя лицевыми счетами. Мы установили, что эти 2 операции, которые взаимодействуют с базой данных, являются операциями транзакции. А какие проблемы могут возникнуть, если мы просто выполним эти операции последовательно, отправив два запроса к БД?

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

В этой ситуации речь идет о проблеме потери данных. В целях снижения этого риска транзакции обладают таким свойством, как атомарность (atomicity), неделимость: либо будут выполнены все действия транзакции, либо никакие.

Блокчейн

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

Одна из ключевых особенностей TON — смарт-контракты, которые могут исполняться параллельно благодаря мультипотоковости. Если представить блокчейн, как магазин, то сети прошлого поколения — это небольшие торговые точки с одной кассой. Чем больше покупателей, тем длиннее очередь и время обслуживания. Блокчейн нового поколения подстраивается под нагрузку, открывая новые кассы при увеличении количества посетителей. Именно на такой архитектуре построен TON.

Благодаря этой и множеству других технических особенностей, блокчейн TON планирует объединить в себе существующие блокчейны и сервисы, а также позволить создавать новые на базе The Open Network, чтобы создать всемирную сеть, где разные блокчейны тесно связаны друг с другом и с централизованным миром.

Выборы

Процесс валидирования в сети TON разбит на раунды, которые длятся примерно по 18 часов, всё начинается с выборов. Все желающие могут подать заявки через специальный смарт-контракт, после чего формируется список по убыванию величины ставки, минимальный порог для того чтобы стать валидатором начинается с 400 000 TON. Если активных заявок больше, чем максимально возможное количество валидаторов, заявки с меньшей ставкой отклоняются. Любые решения в рамках одного раунда принимаются только при достижении консенсуса, для этого требуется собрать подписи не менее 2/3 (66,67%) валидаторов.

Инструкцию по настройке и запуску валидатора вы найдёте здесь.

Возможные решения

Двухфазная фиксация
Согласованность в конечном счете и компенсация / SAGA

1. Двухфазная фиксация

Как это работает

Рисунок 3: успешная двухфазная фиксация в микросервисной системеРисунок 4: Неудавшаяся двухфазная фиксация при работе с микросервисами

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

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

2. Согласованность в конечном счете и компенсация / SAGA

каждый сервис публикует событие всякий раз, когда обновляет свои данные. Другие сервисы подписываются на события. При получении события сервис обновляет свои данные

Как это работает

Рисунок 5: Согласованность в конечном счете / SAGA, успешный исходРисунок 6: Согласованность в конечном счете / SAGA, неудачный исход

Смарт контракты

Асимметрия записи и фантомы

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

Теперь представим, что Алиса и Боб — два дежурных доктора на конкретной смене. Оба плохо себя чувствуют, и оба решили попросить отгул. К сожалению, они нажали на кнопку запроса отгула примерно в одно время. Происходящее после этого показано на рис. 1.

Рис. 1 — Пример асимметрии записи, вызванной ошибкой в коде приложения

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

Такая аномалия носит название асимметрии записи (write skew). Это не «грязная» операция записи и не потеря обновления, поскольку две наши транзакции обновляют два различных объекта. Наличие конфликта тут менее заметно, но это, безусловно, состояние гонки: если две транзакции выполнялись бы одна за другой, то второй врач не получил бы отгула.

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

Предложение FOR UPDATE указывает базе установить блокировку на все возвращенные данным запросом строки.

В примере с дежурными врачами измененная строка была одной из строк, возвращенных в первом запросе, так что можно было обезопасить транзакцию и избежать асимметрии записи, блокируя строки (SELECT FOR UPDATE). Однако если выполняется проверка на отсутствие удовлетворяющих определенному условию поиска строк, а операция записи вставляет соответствующую этому же условию строку, то первый запрос на получения данных не вернет ничего и SELECT FOR UPDATE не на что будет устанавливать блокировки.

Такой эффект, при котором операция записи в одной транзакции меняет результат запроса на поиск в другой, называется фантомом (phantom).

Для предотвращения таких ситуация в большинстве случаев предпочтительнее использовать изоляцию уровня сериализуемости.

Уровень изоляции Serializable

Изоляция уровня Serializable обеспечивает беспрепятственный доступ к базе данных транзакциям с SELECT запросами. Но для транзакций с запросами UPDATE и DELETE, уровень изоляции Serializable не допускает модификации одной и той же строки в рамках разных транзакций. При изоляции такого уровня все транзакции обрабатываются так, как будто они все запущены последовательно (одна за другой). Если две одновременные транзакции попытаются обновить одну и туже строку, то это будет не возможно. В таком случае PostgreSQL принудит транзакцию, вторую, да и все последующие, что пытались изменить строку к отмене (откату — ROLLBACK).

Суть уровня изоляции Serializable показана на диаграмме 2.

Примечание. На диаграмме не показано действие запроса INSERT. В рамках данного уровня изоляции, строки добавленные, например в шаге 3, в Первой транзакции, были бы НЕ ДОСТУПНЫ Второй, Третьей и Четвёртой транзакциям после завершения Первой транзакции. Также на диаграмме не показан результат ROLLBACK (Шаги 8 и 11). В случае если бы Вторая и Третья транзакции делали какие либо изменения над не заблокированными данными, то все эти изменения не были бы зафиксированы, так как транзакции завершаются неудачно (суть свойства — Atomicity).

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

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

Что такое транзакция (transaction)?

Транзакция — это некий набор связанных операций с базой данных.

В первом приближении это действительно так. Однако, пока определение неполное. Не хватает самого главного, а именно — этот набор операций должен представлять единую логическую систему с данными.

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

С первого лицевого счета происходит списание N-ой суммы денежных средств.
На второй лицевой счет идет зачисление этой же суммы.

В данном случае эти две операции связаны и составляют единую логическую систему работы с данными. Теперь можно дать полное определение транзакции.

Транзакция — это набор последовательных операций с базой данных, соединенных в одну логическую единицу.

Часто задаваемые вопросы

Как TON связан с Telegram сейчас?

По условиям соглашения с SEC команда мессенджера не может продолжать участие в разработке, тем не менее сообщество уже интегрирует TON в мессенджер Telegram посредством альтернативных версий мессенджера и ботов (например @CryptoBot).

Как распределены монеты в TON?

Для того чтобы обеспечить справедливое распределение тестовых монет между участниками сообщества, желавшим продолжить работу над сетью, Telegram перевёл основную массу монет на специальные смарт-контракты . Спустя время тестовые монеты обрели ценность, сеть «testnet2» была переименована на «mainnet».

Такой тип распределения имеет очевидные преимущества, такие как децентрализация и равные условия получения монет для всех.

Актуальный баланс , сложность и статистику майнинга вы можете найти в разделе Майнинг на официальном сайте.

Обработка распределенных транзакций в микросервисной архитектуре +13

07.10.20 07:15

•
ph_piter
•
#522366
•
Хабрахабр

•
Перевод

•

5600

Программирование, Распределённые системы, Блог компании Издательский дом «Питер», Исследования и прогнозы в IT, Микросервисы
Рекомендация: подборка платных и бесплатных курсов 3D max — https://katalog-kursov.ru/

Привет, Хабр!
Сегодня мы предлагаем вашему вниманию небольшой материал о микросервисах и распределенной архитектуре. Он, в частности, затрагивает идею Мартина Фаулера о том, что новая система должна начинаться с монолита, а даже в развитой микросервисной архитектуре целесообразно оставлять большое монолитное ядро.
Приятного чтения!
Сегодня все только и размышляют о микросервисах, а также пишут их – и я не исключение. Если исходить из базовых принципов микросервисов и их истинного контекста, то понятно, что микросервисы – это распределенная система.

Чтение зафиксированных данных

Этот уровень изоляции обеспечивает две гарантии:

При чтении из БД клиент видит только зафиксированные данные (никаких «грязных» операций чтения).
При записи в БД можно перезаписывать только зафиксированные данные (никаких «грязных» операций записи).

Если транзакция записала данные в базу, но еще не была зафиксирована или была прервана и другая транзакция увидела эти незафиксированные данные, то такая операция чтения называется «грязной» (dirty read).

Выполняемые при уровне изоляции транзакций read committed (чтение зафиксированных данных) транзакции должны предотвращать «грязные» операции чтения. Это значит, что любые операции записи, выполняемые транзакцией, становятся видны другим транзакциям только после фиксации данной.

Рис. 2 — Никаких «грязных» операций чтения: пользователь 2 видит новое значение x только после фиксации результатов транзакции, выполняемой пользователем 1

Если более ранняя операция записи представляет собой часть еще не зафиксированной транзакции и более поздняя транзакция перезаписывает незафиксированное значение, то такая операция называется «грязной» операцией записи.

Чтение зафиксированных данных предотвращает казусы, например, как на рис. 3, связанные с грязной операцией записи.

Рис. 3 — В случае «грязных» операций записи конфликтующие операции записи различных транзакций могут оказаться перепутаны

Чтение зафиксированных данных — очень популярный уровень изоляции. Он используется по умолчанию в Oracle 11g, PostgreSQL, SQL Server 2012, MemSQL и многих других базах данных.

Чаще всего базы используют блокировки строк для предотвращения «грязных» операций записи: прежде чем модифицировать конкретный объект (строку или документ), транзакция должна сначала установить блокировку на этот объект. Данная блокировка должна удерживаться вплоть до фиксации или прерывания транзакции. Удерживать блокировку на конкретный объект может только одна транзакция одновременно, другой транзакции, желающей выполнить операцию записи в этот объект, придется дождаться фиксации или прерывания первой транзакции и лишь затем получить на него блокировку и продолжить свою работу. Подобные блокировки выполняются базами автоматически в режиме чтения зафиксированных данных (и на более сильных уровнях изоляции).

Большинство БД предотвращают «грязные» операции чтения с помощью подхода, показанного на рис. 2: база запоминает для каждого записываемого объекта как старое зафиксированное значение, так и новое, устанавливаемое транзакцией, удерживающей в данный момент блокировку записи. Во время выполнения транзакции всем другим транзакциям, читающим объект, просто возвращается старое значение. Только после фиксации нового значения транзакции начинают получать его при чтении.

Заключение

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

В конце концов, неважно, какую стратегию вы выберете; что имеет значение, так это осознанный выбор стратегии и правильная ее реализация

Заключение

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

Мы рассказали про 5 платформ:

Chainalysis — отслеживает транзакции внутри блокчейна и проверяет открытые источники информации. Также на платформе есть самый крупный справочник блокчейн-сервисов.
Crystal Blockchain — анализирует 98% блокчейн-транзакций и визуализирует криптовалютные потоки.
Elliptic — хранит информацию о 20 млрд данных из блокчейна.
CipherTrace — анализирует 87% объема транзакций мирового блокчейна и проводит судебную экспертизу.
AMLBot — работает не только с бизнес-компаниями, но и физическими лицами. Официальный партнер платформы Crystal Blockchain.

Редактор:Дмитрий Егоров

Обложка и иллюстрации:Юлия Чистякова

Заключение

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