Работа с согласованностью чтения путем повторной попытки GetItem

Я создаю API №1, который создает элемент в DynamoDB. Я создаю другой API № 2, который извлекает элемент с помощью GSI (входной ключ может не существовать). Но чтение GSI может быть согласованным только в конечном итоге, и мне не нужен сценарий, в котором API № 1 создает элемент, а API № 2 не получает этот элемент.

Так что я думаю об этом:

  1. API №1 создает элемент через UpdateItem
  2. API №1 пытается получить элемент с помощью GSI через GetItem. Продолжает повторять попытки с экспоненциальной задержкой, пока не получит элемент. Как только это произойдет, окончательная согласованность должна закончиться.
  3. API № 2 извлекает элемент, используя тот же GSI, что и выше, через GetItem. Поскольку API № 1 уже получил элемент, он должен получить элемент с первой попытки.

Примечание. Я не думаю, что API № 2 может вместо этого выполнять повторные попытки GetItem, потому что его входной ключ может никогда не существовать.

Будет ли это работать? Есть ли лучшие решения?


amazon-web-services amazon-dynamodb eventual-consistency
person onepiece    schedule 13.08.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Я не смог найти (и я пытался тщательно искать...) какой-либо документации, гарантирующей, что согласованные в конечном итоге операции чтения DynamoDB имеют монотонную согласованность чтения. Основываясь на презентациях, которые я видел по реализации DynamoDB (у меня нет никаких внутренних знаний), я считаю, что на самом деле она не имеет монотонной согласованности чтения:

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

  1. Предполагается, что запись обновит три копии GSI на трех узлах — X, Y и Z — но на данный момент обновлены только X и Y, а Z еще нет.
  2. API 1 считывает из GSI и случайным образом запрашивает узел X и получает новое значение.
  3. Теперь API 2 читает из GSI. Он случайным образом получает узел Z и получает старое значение!

Таким образом, возможно, что после того, как ваше приложение найдет новое значение, другое чтение не найдет его :-(

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

person Nadav Har'El    schedule 13.08.2020