6.2 分布式锁定

通常，当您“锁定”数据时，您首先获取锁，从而使您对数据具有独占访问权。然后，您执行操作。最后，您释放锁以供他人使用。 获取、操作、释放的顺序在线程访问的共享内存数据结构的上下文中非常有名。 在 Redis 的上下文中，我们一直在使用 WATCH 作为锁的替代品，我们称之为乐观锁定，因为它实际上并没有阻止其他人修改数据，而是当其他人更改数据时我们会收到通知 自己做之前。

通过分布式锁定，我们具有相同的获取、操作、释放操作，但是，我们不是使用仅由同一进程中的线程或同一机器上的进程知道的锁，而是使用不同的 Redis 客户端可以在不同机器上获取和释放的锁。 何时以及是否使用锁或 WATCH 将取决于给定的应用程序； 有些应用程序不需要锁即可正确运行，有些应用程序只需要部分锁，而有些应用程序则需要在每个步骤都使用锁。

我们花费大量时间使用 Redis 构建锁而不是使用操作系统级别的锁、语言级别的锁等等的一个原因是范围问题。 客户端希望对存储在 Redis 上的数据具有独占访问权限，因此客户端需要访问在所有客户端都可以看到的范围（Redis）中定义的锁。 Redis 确实具有作为命令集的一部分已经可用的基本锁类型 (SETNX)，我们使用它，但它功能不全，并且不提供用户期望的分布式锁的高级功能。

在本节中，我们将讨论过载的 WATCHed 密钥如何导致性能问题，并逐步构建锁，直到我们可以替换某些情况下的 WATCH。