この記事では、Redis に関する関連知識を提供します。主に分散ロックに関連する問題を紹介します。ロックを呼び出したりロックを解放したりするために通常スレッドと呼ばれるものは、実際には上記のとおりです。スレッドがロック操作を呼び出すとき、実際には、ロック変数の値が 0 かどうかをチェックします。皆さんのお役に立てれば幸いです。
推奨される学習: Redis 学習チュートリアル
まず、単一マシン上のロックを見てみましょう。
単一マシン上で実行されるマルチスレッド プログラムの場合、ロック自体は変数で表すことができます。
通常、スレッドはロック操作と解放操作を呼び出すと言いますが、実際には、スレッドがロック操作を呼び出すとき、実際にはロック変数の値が 0 であるかどうかを確認します。 0 の場合は、ロック変数値を 1 に設定し、ロックが取得されたことを示します。0 でない場合は、ロックが失敗し、別のスレッドがロックを取得したことを示すエラー メッセージが返されます。スレッドがロック解放操作を呼び出すと、他のスレッドがロックを取得できるように、実際にはロック変数の値が 0 に設定されます。
コードの一部を使用して、ロックとロックの解放の操作を示します。ここで、lock はロック変数です。
acquire_lock(){
if lock == 0
lock = 1
return 1
else
return 0
}
release_lock(){
lock = 0
return 1
}
単一マシンのロックと同様に、分散ロックも変数を使用して 実装できます。クライアントでのロックとロックの解放の操作ロジックは、単一マシンでのロックとロックの解放の操作ロジックと一致しています。 ロックするときにロック変数の値を判断し、ロックされているかどうかを判断することも必要です。ロックはロック変数の値に基づいて成功する可能性があります。 ; ロックを解放するときは、ロック変数の値を 0 に設定する必要があります。これは、クライアントがロックを保持していないことを示します。
ただし、単一マシン上でロックを操作するスレッドとは異なり、分散シナリオでは、ロック変数は共有ストレージ システムによって維持される必要があります。この方法でのみ、複数のクライアントのロック変数を管理できます。共有ストレージ システムにアクセスすることでアクセスできます。同様に、ロックとロックの解放の操作は、共有ストレージ システムのロック変数値の読み取り、判断、および設定になります。
このようにして、分散ロックを実装するための 2 つの要件を導き出すことができます。
要件 1: 分散ロックのロックと解放のプロセスには複数の操作が含まれます。したがって、分散ロックを実装するときは、これらのロック操作のアトミック性を確保する必要があります;
要件 2: 共有ストレージ システムはロック変数を保存します。共有ストレージ システムに障害が発生するかダウンすると、クライアントはロック変数を保存できなくなります。ロックが作動します。分散ロックを実装する場合は、共有ストレージ システムの信頼性、ひいてはロックの信頼性の確保を考慮する必要があります。
さて、特定の要件がわかったところで、Redis が分散ロックを実装する方法を学びましょう。
実際には、単一の Redis ノードに基づいて実装することも、複数の Redis ノードを使用することもできます。これら 2 つのケースでは、ロックの信頼性は同じではありません。まず、単一の Redis ノードに基づく実装方法を見てみましょう。
単一 Redis ノードに基づく分散ロックの実装
分散ロックの実装における共有ストレージ システムとして、Redis はキーと値のペアを使用してロック変数を保存できます。さまざまなクライアントから送信されたロックとロックの解放の操作リクエストを受信して処理します。では、キーと値のペアのキーと値はどのように決定されるのでしょうか?
ロック変数に変数名を付け、この変数名をキーと値のペアのキーとして使用する必要があり、ロック変数の値はキーと値のペアの値になります。ロック変数を保存できるクライアント側は、Redis コマンド操作を通じてロック操作を実装することもできます。
理解を助けるために、キーと値のペアを使用してロック変数を保存する Redis と、同時にロックを要求する 2 つのクライアントの操作プロセスを示す図を描きました。 
ご覧のとおり、Redis はキーと値のペア lock_key:0 を使用してロック変数を保存できます。ここで、キーは lock_key であり、これはロック変数の名前でもあります。ロック変数の初期値は 0 です。
もう一度ロック操作を分析してみましょう。
図では、クライアント A とクライアント C が同時にロックを要求しています。 Redis は単一のスレッドを使用してリクエストを処理するため、クライアント A と C が同時にロック リクエストを Redis に送信した場合でも、Redis はそれらのリクエストを順番に処理します。
Redis が最初にクライアント A のリクエストを処理し、lock_key の値を読み取り、lock_key が 0 であることを検出したとします。したがって、Redis は lock_key の値を 1 に設定し、ロックされていることを示します。その直後、Redis はクライアント C のリクエストを処理します。このとき、Redis は lock_key の値がすでに 1 であることに気づき、ロック失敗情報を返します。
今話したのはロック操作ですが、ロックを解除するにはどうすればよいでしょうか?実際、ロックを解放するということは、ロック変数の値を直接 0 に設定することを意味します。
我还是借助一张图片来解释一下。这张图片展示了客户端 A 请求释放锁的过程。当客户端 A 持有锁时，锁变量 lock_key 的值为 1。客户端 A 执行释放锁操作后，Redis 将 lock_key 的值置为 0，表明已经没有客户端持有锁了。
因为加锁包含了三个操作（读取锁变量、判断锁变量值以及把锁变量值设置为 1），而这三个操作在执行时需要保证原子性。那怎么保证原子性呢？
要想保证操作的原子性，有两种通用的方法，分别是使用 Redis 的单命令操作和使用 Lua 脚本。那么，在分布式加锁场景下，该怎么应用这两个方法呢？
我们先来看下，Redis 可以用哪些单命令操作实现加锁操作。
首先是 SETNX 命令，它用于设置键值对的值。具体来说，就是这个命令在执行时会判断键值对是否存在，如果不存在，就设置键值对的值，如果存在，就不做任何设置。
举个例子，如果执行下面的命令时，key 不存在，那么 key 会被创建，并且值会被设置为 value；如果 key 已经存在，SETNX 不做任何赋值操作。
SETNX key value
对于释放锁操作来说，我们可以在执行完业务逻辑后，使用 DEL 命令删除锁变量。不过，你不用担心锁变量被删除后，其他客户端无法请求加锁了。因为 SETNX 命令在执行时，如果要设置的键值对（也就是锁变量）不存在，SETNX 命令会先创建键值对，然后设置它的值。所以，释放锁之后，再有客户端请求加锁时，SETNX 命令会创建保存锁变量的键值对，并设置锁变量的值，完成加锁。
总结来说，我们就可以用 SETNX 和 DEL 命令组合来实现加锁和释放锁操作。下面的伪代码示例显示了锁操作的过程，你可以看下。
// 加锁 SETNX lock_key 1 // 业务逻辑 DO THINGS // 释放锁 DEL lock_key
不过，使用 SETNX 和 DEL 命令组合实现分布锁，存在两个潜在的风险。
第一个风险是，假如某个客户端在执行了 SETNX 命令、加锁之后，紧接着却在操作共享数据时发生了异常，结果一直没有执行最后的 DEL 命令释放锁。因此，锁就一直被这个客户端持有，其它客户端无法拿到锁，也无法访问共享数据和执行后续操作，这会给业务应用带来影响。
针对这个问题，一个有效的解决方法是，给锁变量设置一个过期时间。这样一来，即使持有锁的客户端发生了异常，无法主动地释放锁，Redis 也会根据锁变量的过期时间，在锁变量过期后，把它删除。其它客户端在锁变量过期后，就可以重新请求加锁，这就不会出现无法加锁的问题了。
我们再来看第二个风险。如果客户端 A 执行了 SETNX 命令加锁后，假设客户端 B 执行了 DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁，就可以成功获得锁，进而开始操作共享数据。这样一来，客户端 A 和 C 同时在对共享数据进行操作，数据就会被修改错误，这也是业务层不能接受的。
为了应对这个问题，我们需要能区分来自不同客户端的锁操作，具体咋做呢？其实，我们可以在锁变量的值上想想办法。
在使用 SETNX 命令进行加锁的方法中，我们通过把锁变量值设置为 1 或 0，表示是否加锁成功。1 和 0 只有两种状态，无法表示究竟是哪个客户端进行的锁操作。所以，我们在加锁操作时，可以让每个客户端给锁变量设置一个唯一值，这里的唯一值就可以用来标识当前操作的客户端。在释放锁操作时，客户端需要判断，当前锁变量的值是否和自己的唯一标识相等，只有在相等的情况下，才能释放锁。这样一来，就不会出现误释放锁的问题了。
知道了解决方案，那么，在 Redis 中，具体是怎么实现的呢？我们再来了解下。
在查看具体的代码前，我要先带你学习下 Redis 的 SET 命令。
我们刚刚在说 SETNX 命令的时候提到，对于不存在的键值对，它会先创建再设置值（也就是“不存在即设置”），为了能达到和 SETNX 命令一样的效果，Redis 给 SET 命令提供了类似的选项 NX，用来实现“不存在即设置”。如果使用了 NX 选项，SET 命令只有在键值对不存在时，才会进行设置，否则不做赋值操作。此外，SET 命令在执行时还可以带上 EX 或 PX 选项，用来设置键值对的过期时间。
举个例子，执行下面的命令时，只有 key 不存在时，SET 才会创建 key，并对 key 进行赋值。另外，key 的存活时间由 seconds 或者 milliseconds 选项值来决定。
SET key value [EX seconds | PX milliseconds] [NX]
有了 SET 命令的 NX 和 EX/PX 选项后，我们就可以用下面的命令来实现加锁操作了。
// 加锁, unique_value作为客户端唯一性的标识
SET lock_key unique_value NX PX 10000
其中，unique_value 是客户端的唯一标识，可以用一个随机生成的字符串来表示，PX 10000 则表示 lock_key 会在 10s 后过期，以免客户端在这期间发生异常而无法释放锁。
因为在加锁操作中，每个客户端都使用了一个唯一标识，所以在释放锁操作时，我们需要判断锁变量的值，是否等于执行释放锁操作的客户端的唯一标识，如下所示：
//释放锁 比较unique_value是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
这是使用 Lua 脚本（unlock.script）实现的释放锁操作的伪代码，其中，KEYS[1]表示 lock_key，ARGV[1]是当前客户端的唯一标识，这两个值都是我们在执行 Lua 脚本时作为参数传入的。
最后，我们执行下面的命令，就可以完成锁释放操作了。
redis-cli --eval unlock.script lock_key , unique_value
你可能也注意到了，在释放锁操作中，我们使用了 Lua 脚本，这是因为，释放锁操作的逻辑也包含了读取锁变量、判断值、删除锁变量的多个操作，而 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，从而保证了锁释放操作的原子性。
好了，到这里，你了解了如何使用 SET 命令和 Lua 脚本在 Redis 单节点上实现分布式锁。但是，我们现在只用了一个 Redis 实例来保存锁变量，如果这个 Redis 实例发生故障宕机了，那么锁变量就没有了。此时，客户端也无法进行锁操作了，这就会影响到业务的正常执行。所以，我们在实现分布式锁时，还需要保证锁的可靠性。那怎么提高呢？这就要提到基于多个 Redis 节点实现分布式锁的方式了。
基于多个 Redis 节点实现高可靠的分布式锁
当我们要实现高可靠的分布式锁时，就不能只依赖单个的命令操作了，我们需要按照一定的步骤和规则进行加解锁操作，否则，就可能会出现锁无法工作的情况。“一定的步骤和规则”是指啥呢？其实就是分布式锁的算法。
为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。
Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。
我们来具体看下 Redlock 算法的执行步骤。Redlock 算法的实现需要有 N 个独立的 Redis 实例。接下来，我们可以分成 3 步来完成加锁操作。
第一步是，客户端获取当前时间。
第二步是，客户端按顺序依次向 N 个 Redis 实例执行加锁操作。
这里的加锁操作和在单实例上执行的加锁操作一样，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标识。当然，如果某个 Redis 实例发生故障了，为了保证在这种情况下，Redlock 算法能够继续运行，我们需要给加锁操作设置一个超时时间。
如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。
第三步是，一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。
客户端只有在满足下面的这两个条件时，才能认为是加锁成功。
在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。
当然，如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么，客户端向所有 Redis 节点发起释放锁的操作。
Redlock アルゴリズムでは、ロックを解放する操作は単一インスタンスのロックを解放する操作と同じであり、ロックを解放する Lua スクリプトを実行するだけです。このように、N 個の Redis インスタンスの半分以上が正常に動作できる限り、分散ロックの正常な動作が保証されます。
したがって、実際のビジネス アプリケーションでは、分散ロックの信頼性を向上させたい場合は、Redlock アルゴリズムを通じてそれを実現できます。
推奨学習: Redis 学習チュートリアル
以上がRedis を使用して分散ロックを実装する方法について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。