Как сделать атомное обновление с etcd

Question

Я пытаюсь понять, что такое «атомное» обновление в терминах на etcd.

Когда я думаю, что «атомный», я думаю, что есть «до» и «после» (во время нет, и если обновление не удается, оно все еще «до»).

Вот пример:

curl -s -XPUT http://localhost:2379/v2/keys/message -d value='Hidee Ho' 

Таким образом, на данный момент, любой желающий может получить доступ к этому сообщению и получить текущее значение:

curl -s http://localhost:2379/v2/keys/message 
{"action":"get","node":{"key":"/message","value":"Hidee Ho","modifiedIndex":4748,"createdIndex":4748}} 

Позже, я могу изменить это значение, как это:

curl -s -XPUT http://localhost:2379/v2/keys/message -d value='Mr Hanky' 

И результат может быть получен, как и раньше. Перед моим изменением возвращается значение «Hidee Ho», после изменения значение «Mr Hanky» возвращается. Итак, мой вопрос: я гарантирую тот или иной результат? То есть, я хочу подтвердить, что тот или иной будет возвращен (а не ноль значение между результатом).

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

Я смущен, потому что есть функция Atomic CompareAndSwap в протоколе. Насколько я могу судить, это не так много Atomic, как «только обновление, если значение - это то, что я говорю». В моем случае мне все равно, какова была ценность. Я просто хочу знать, что он изменен и что никакие читатели не видят ничего, кроме значений «до» или «после».

Answer 1

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

Функция CompareAndSwap позволяет оптимизировать блокировку, чтобы вы могли писать новые значения, которые зависят от предыдущего значения, например. счетчик. Если бы вы использовали счетчик без использования CompareAndSwap, у вас было бы что-то вроде write("count", 1 + read("count")), в этом случае чтение и запись были бы раздельными, если бы два вызывающих абонента сделали это одновременно, то, возможно, они оба увидели бы тот же старт значение, и вы потеряете один из приращений. используя CAS, вызывающий может сказать, что установить его на 12, только если предыдущее значение равно 11, теперь, если это произойдет одновременно, одна из записей завершится неудачей, и затем она может перечитать и повторно применить ее дельту, чтобы вы не потеряли любые приращения.