6.2.2 简单锁

在我们第一个简单的锁版本中，我们将注意到一些不同的潜在失败场景。当我们真正开始构建锁时，我们不会立即处理所有故障。相反，我们将尝试使基本的获取、操作和释放过程正常工作。在我们使其正常工作并展示如何使用锁可以实际提高性能之后，我们将处理我们尚未处理的任何失败情况。

在使用锁时，有时客户端可能会由于某种原因而无法释放锁。为了防止客户端可能崩溃并将锁留在已获取状态的故障，我们最终将添加一个超时，如果拥有该锁的进程未在给定时间内完成，则该超时会导致自动释放该锁。

许多 Redis 用户已经了解锁、锁定和锁超时。但可悲的是，Redis 中锁的许多实现只是大部分正确。大部分正确的锁的问题在于，它们会在我们不期望的方式中失败，尤其是在我们不期望它们失败的时候。以下是一些可能导致不正确行为的情况，以及行为不正确的具体方式

• 一个进程获取了一个锁，对数据进行了操作，但花费的时间太长，并且该锁被自动释放。该进程不知道它丢失了锁，甚至可能释放某些其他进程随后获得的锁。
• 一个进程为一个需要很长时间的操作获取了一个锁并崩溃了。想要该锁的其他进程不知道哪个进程拥有该锁，因此无法检测到该进程失败，并且浪费时间等待该锁被释放。
• 一个进程拥有一个锁，但它超时了。其他进程同时尝试获取该锁，并且多个进程能够获得该锁。
• 由于第一个和第三个场景的组合，现在许多进程都持有该锁，并且都认为它们是唯一的持有者。

即使这些问题中的每一个都只有百万分之一发生的几率，但由于 Redis 可以在最新的硬件上每秒执行 100,000 次操作（在高端硬件上每秒最多可执行 225,000 次操作），因此在负载较重的情况下可能会出现这些问题，因此正确锁定非常重要。