2

マルチインスタンス ワーカー ロール用に、Azure 上の Redis 内に分散ロックを作成しようとしています。ワーカー ロールの複数のインスタンス間で、一度に 1 つのスレッドだけがアクセスできる「クリティカル セクション」を作成する方法が必要です。

私はこれを行うために StackExchange.Redis クライアントを使用していますが、便利なことに、TakeLock\ReleaseLock すでにtransactional の実装があり、 SO に関するこの回答は、使用するパターンとロックの作成方法の詳細についての良いアイデアを与えてくれます。

この件についてさらに読むと、distlock に関するこの Redis の記事も読みました。この記事では、分散ロック メカニズムを実装しようとするときのフェイルオーバー ベースの Redis ノードの弱点について説明しています。

Azure Redis キャッシュは (基本層とは別に) マスター/スレーブ フェールオーバーを実装していますが、これは、 1 つのものだけがロックされることを保証するために、レッドロックパターンを実装する必要があることを意味しますか?

さらに、私は疑問に思っています：

  • Azure Redis の例の接続文字列にマスターとスレーブがリストされていないように見えるのはなぜですか? Azure はマスター/スレーブ フェールオーバーを別の方法で実装しましたか?
  • redlock の.NET 実装の 1 つが、マスター/スレーブの使用をサポートしないことを選択したのはなぜですか? (使用法セクションの最初の段落を参照) これは単に選択によるものですか、それともマスター/スレーブが redlock の有効な使用法ではないためですか ( redis の記事ではそうではないようです)
4

1 に答える 1

3

I'm the author of the RedLock.net library that you linked in your question. The reason the documentation specifies connecting to independent redis instances is based on the reasoning in the Redis Distlock documentation. By forcing writes only to master nodes, we hopefully avoid the situation where a user might misconfigure Redlock to connect to multiple replicated hosts.

According to Azure Redis Cache 103 - Failover and Monitoring there is a load balancer in front of an Azure Redis Cache (at the standard tier and above) that ensures that you are always connected to the master.

Connecting to multiple redis instances (either replicated or not) should give a fairly good guarantee that no two processes end up running at the same time (moreso than a single replicated instance).

In order for another process to 'steal' the lock before the first had finished, more than half of the independent redis instances would need to lose their lock keys (e.g. by restarting without persistence), then have process two gain the lock before the timer in process one reacquired it during its extend timer.

于 2016-01-25T17:20:32.103 に答える