4

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' が返されます。それで、私の質問は、どちらかの結果が保証されているのですか? つまり、どちらか一方が返されることを確認したい (結果の間にnil値ではない)。

タイミングは特に気にしません。Mr Hanky の更新を行い、その後の値のフェッチャーが (短い) 期間、Hidee Ho を取得し続ければ、それで問題ありません。

プロトコルにAtomic CompareAndSwap関数があるため、混乱しています。私が知る限り、それは「値が私が言うとおりの場合にのみ更新を行う」ほどアトミックではありません。私の場合、以前の値はあまり気にしません。変更されたこと、および「前」または「後」の値以外は読者に表示されないことを知りたいだけです。

4

1 に答える 1

8

クライアントには以前の値または新しい値のみが表示されるという点で、プレーンな PUT はアトミックであるという点で正しいです。

CompareAndSwap 機能を使用すると、楽観的ロックを実行できるため、カウンターなど、前の値に依存する新しい値を書き込むことができます。CompareAndSwap を使用せずにカウンターを実装する場合は、次のようwrite("count", 1 + read("count"))になります。この場合、読み取りと書き込みは別々です。2 つの呼び出し元が同時にこれを行った場合、両方が同じ開始値を参照する可能性があります。 、増分の 1 つを失うことになります。CAS を使用すると、呼び出し元は、前の値が 11 の場合にのみ 12 に設定すると言うことができます。これが同時に発生した場合、書き込みの 1 つが失敗し、そのデルタを再読み取りして再適用できるため、失われることはありません。任意の増分。

于 2015-06-17T01:12:09.000 に答える