Aerospike ACID - Как узнать окончательный результат транзакции по таймаутам?

Question

Я новичок в Aerospike.

Я хотел бы знать, что во всех возможных сценариях тайм-аута, как указано в этой ссылке:

https://discuss.aerospike.com/t/understanding-timeout-and-retry-policies/2852

1. Клиент можетне подключаться по указанному таймауту (timeout =).Тайм-аут, равный нулю, означает, что тайм-аут не установлен.

2. Клиент не получает ответ по указанному тайм-ауту (timeout =).

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

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

5. Клиент не может получить действительный узел после N попыток (когда повторные попытки установлены от вашего клиента).

6. Клиент не может получитьдействительное соединение после X повторных попыток.Количество повторных попыток обычно является ограничивающим фактором, а не значением времени ожидания.Причина заключается в том, что если вы не можете получить соединение после повторных попыток R, вы никогда этого не сделаете, поэтому просто сделайте тайм-аут раньше.

Из всех упомянутых сценариев тайм-аута, при которых обстоятельства могутЯ был абсолютно уверен, что окончательный результат сделки не удалось?

Предлагает ли Aerospike что-то, например, откат транзакции, если клиент не отвечает?

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

Заранее большое спасибо.

Редактировать: Мы нашли временное решение:

Держите карту[generation -> value read] для этой записи (возможно, фоновый поток, постоянно читающий запись и т. д.), а затем по тайм-аутам мы периодически проверяем карту (ключ = ожидаемое поколение), чтобы увидеть, действительно ли записанное значение действительноодин положил на карту.Если они одинаковы, это означает, что запись прошла успешно, иначе это означает, что запись не удалась.

Вы, ребята, думаете, что это необходимо сделать?Или есть другой способ?

Answer 1

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

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

Я использовал следующий метод:

1. Каждой записи потребуется список, а список будет содержать последние N идентификаторов транзакций.
   • Для моего случая использования я дал каждому клиенту уникальный 2-байтовый идентификатор - каждому клиентскому потоку уникальный 2-байтовый идентификатор - и каждый клиентский поток имел 4-байтовый счетчик.Таким образом, конкретный идентификатор транзакции будет выглядеть так, как если бы он маскировал 8-байтовый идентификатор из 2 идентификаторов и счетчика.
2. * Считывание метаданных записей с помощью getHeader api -это позволяет избежать чтения бункеров записей из хранилища.
   • Примечание. Мой вариант использования не был шагом, поэтому мне пришлось читать записи и писать с проверкой генерации.Этот шаблон должен быть более эффективным для случая использования счетчика.
3. Записать запись, используя операторы и gen-equal для генерации чтения с помощью этих операций: увеличитьцелочисленный bin, перед списком txns и trim списком txns.Вы добавите свой идентификатор транзакции в свой список txns, а затем урежете список до максимального размера выбранного вами списка.
   • N должно быть достаточно большим, чтобы у записи было достаточно времени для проверки транзакции, учитывая конфликт по ключу.Значение N будет влиять на сохраненный размер записи, поэтому выбор слишком большого будет стоить дискового ресурса, а выбор слишком маленького сделает алгоритм неэффективным.
4. Если транзакция прошла успешно, значит, все готово.
5. Если транзакция 'inDoubt', прочитайте ключ и проверьте список txns для вашего идентификатора транзакции.Если он присутствует, то ваша транзакция «определенно успешно».
6. Если ваш идентификатор транзакции отсутствует в txns, повторите шаг 3 с генерацией, возвращенной из чтения на шаге 5.
7. Вернуться к шагу3 - за исключением того, что на шаге 5 «ошибка генерации» также должна рассматриваться как «сомнительная», поскольку, возможно, это была предыдущая попытка, которая в итоге применялась.

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

Опять же, с «сильной согласованностью» упоминания «определенно успешно» и «определенно не удалось» являются точными утверждениями, но в AP эти утверждения имеют режимы сбоев (особенно присетевые разделы).

Answer 2

Последние клиенты будут предоставлять дополнительный флаг по тайм-аутам, который называется «в сомнении».Если false, вы уверены, что транзакция не удалась (клиент даже не смог подключиться к узлу, поэтому он не смог отправить транзакцию).Если это правда, то все еще существует неопределенность, так как клиент отправил бы транзакцию, но не знал бы, достигла ли она кластера или нет.1004 * функция, которая может помочь вашему варианту использования.