как мне сделать атомарное обновление с помощью etcd

Я пытаюсь понять, что такое «атомарное» обновление с точки зрения 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'

И результат можно получить, как и раньше. До моего изменения возвращается значение «Хиди Хо», после изменения возвращается значение «Мистер Хэнки». Итак, мой вопрос: гарантирую ли я тот или иной результат? То есть я хочу подтвердить, что будет возвращено одно или другое (а не нулевое значение между результатом).

Я не особенно забочусь о времени. Если я сделаю обновление Mr Hanky, а последующие сборщики значения продолжат получать Hidee Ho в течение (короткого) периода времени, все в порядке.

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


etcd raft
person Greg    schedule 12.06.2015    source источник

Ответы (1)


arrow_upward
7
arrow_downward

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

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

person superfell    schedule 17.06.2015
comment
лучше поздно, чем никогда :-) - person Greg; 17.08.2017