Блог

В документации для потока транзакций hyperled&er fabric упоминается, что

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

У меня здесь есть пара вопросов

1. Что означает «хронологический порядок»?. Означает ли это, что транзакции для канала упорядочиваются в зависимости от времени их получения на узле службы заказа (Leader)?

2. Если два клиентских приложения отправляют транзакцию обновления для одного и того же ключа в главной книге почти в одно и то же время [Назовем их tx1 (обновление ключа x до значения p) , tx2 (обновление ключа x до значения q)], все подтверждающие одноранговые узлы имитируют предложение об обновлении транзакции и возвращают набор записей в ответе на предложение о транзакции. Когда клиенты отправляют эти запросы на одобрение узлам службы заказа, в каком порядке эти транзакции обновления будут упорядочены в блоке ?.

Порядок транзакций в блоке может быть tx1, tx2 или tx2, tx1 , предполагая, что транзакция обновления имеет только набор для записи и не имеет набора для чтения, обе транзакции в любом порядке являются действительными. Каким будет конечное значение ключа в главной книге [p или q]?

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

Что означает «хронологический порядок»?. Означает ли это, что транзакции для канала упорядочиваются в зависимости от времени их получения на узле службы заказа (Leader)?

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

На практике для текущих реализаций упорядочителя обычно справедливо следующее:

Solo — сообщения должны доставляться в том порядке, в котором они были получены

Kafka — сообщения должны доставляться в том порядке, в котором они были получены каждым узлом-заказчиком, и, как правило, даже в том порядке, в котором они получены несколькими узлами-заказчиками.

Это справедливо и для последней версии fabric.

Если два клиентских приложения отправляют транзакцию обновления для одного и того же ключа в главной книге почти в одно и то же время [Назовем их tx1 (обновление ключа x до значения p) , tx2 (обновление ключа x до значения q)], все подтверждающие одноранговые узлы имитируют предложение об обновлении транзакции и возвращают набор записей в ответе на предложение о транзакции. Когда клиенты отправляют эти запросы на одобрение узлам службы заказа, в каком порядке эти транзакции обновления будут упорядочены в блоке ?.

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

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