分散ロック、もう少し深く！！

1. 原因

分散環境では、複数のマシン上の複数のプロセスが 1 つのデータに対して操作を行うため、必然的に「商品の売れ過ぎ」などのデータの不整合が発生します。したがって、分散環境で重要なリソースにどのようにアクセスするかは、インターネットにとって大きな問題です。分散ロックが解決策です。

2. 相互排除の原則

原則: 複数のアクセスパーティが同じリソースを操作する場合、相互排他性が必要です。これは通常、これらのアクセスパーティが同時にアクセスできるロックを使用することで実現されます。

シーン1

同じプロセス内で、複数のスレッドをシリアルアクセス用にロックすることで、それらのスレッドを相互に排他的にすることができます。

ステップ：

ナレーション: ロックはプロセス内のデータ構造であり、重要なリソースをめぐる競合をロック構造をめぐる競合に変換します。

シーン2

分散環境では、プロセス内のロック構造をプロセス外で使用することはできません。では、マルチプロセス環境で重要なリソースをどのように保護すればよいのでしょうか。

インプロセスロックメカニズムと組み合わせると、いくつかの条件を導き出すことができます。

ナレーション: この問題の鍵となるのは、一度に 1 つのプロセスのみが正常にアクセスできる外部ストレージ構造を見つけることです。

3. 分散ロック

分散ロックの核心は適切な外部ストレージを選択することであるため、「適切な」ストレージメディアとストレージモデルを選択する方法が私たちの考え方の核心です。

では、分散ロックではリレーショナルストレージと KV ストレージのどちらを使用すればよいのでしょうか?

ロックの観点からは、それほど多くのことは必要とせず、KV ストレージで十分です。そこで私たちが最初に考えたのは、Redis ソリューションです。 Redis ソリューションは最適なソリューションでしょうか?

Redis: シングルスレッドの高性能インメモリ KV ストレージソリューション。

ステップ：

複数のマシン上の複数のプロセスがこのロックを競い合います。たとえば、キャッシュ上でset key=123操作を同時に実行します。
ロックを取得できるのは 1 つのプロセスのみ、つまり、キャッシュに key=123 を正常に設定できるのは 1 つのプロセスのみであり、失敗したプロセスは次回再試行します。
ロックを取得したプロセスは重要なリソースに対して操作を行う
減算が完了すると、ロックが解除され、つまりキー=123でキャッシュが削除されます。

機能的には、Redis は分散ロックを完璧に実装しています。詳しく見てみましょう。