Redisがシングルスレッドの場合、なぜロックメカニズムが必要なのですか。
Redisは確かに（ほとんど）シングルスレッドですが、複数のクライアントが隣接する時間的近接性で異なることを行おうとすると、ロックが必要になります。 RiAで説明されているロックは、まさにそれに関するものです。1つのクライアント/スレッドのみが特定のタスクを実行するようにするか、更新が失敗しないようにします。
Redisのシングルスレッド性にもかかわらずロックが必要になる理由の例を次に示します。たとえば、fooという名前のキーの下に格納されている数値などの値がRedisにあると仮定します。 。アプリのコードはその番号を読み取ります（GET foo ）、何かを実行し（つまり、1を追加）、それを書き戻します（SET ）。シングルスレッドでコードを実行すると、次のようになります。
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
次に、2つのアプリクライアントがこれを実行しようとするとどうなるかを見てみましょう。
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
ここでは、サーバーが（ほとんど）シングルスレッドであるにもかかわらず、ロックせずに何が起こったかをすぐに確認できます-3ではなくfoo の値は2です。スレッド/クライアント/アプリを追加すると、複数のライターが調整なしでデータを変更しようとすると（ロックなど）、状況が楽しく、ひどく悪くなる可能性があります。
楽観的ロックはそれを行う方法の1つにすぎず、RedisはWATCHを介して組み込みで提供しています。 機構。ただし、楽観主義は、その簡単で幸せな性質にもかかわらず、適切な解決策ではない場合があるため、競合状態を防ぐために、より優れた/高度な/異なるメカニズムを実装する必要があります。このようなロックは、間違いなくRedisの外部でも実装できますが、すでに使用している場合は、その中でロックを管理することも理にかなっています。