干货分享：如何让锁变的更加安全？

我们来看下面的例子：如下图所示，客户端在时间点 S0 尝试去抢锁，在时间点 S1 在后端抢锁成功，因此也产生了一个分布式锁的有效期窗口。在有效期内，时间点 S2 做了一个访问存储的操作，很快完成，然后在时间点 S3 判断锁的有效期依旧成立，继续执行访问存储操作，结果这个操作耗时良久，超过了分布式锁的过期时间，那么可能这个时候，分布式锁已经被其他客户端抢占成功，进而出现两个客户端同时操作同一批数据的可能性，这种可能性是存在的，虽然概率很小。

针对这个场景，我们也是有方案可以应对的，在操作数据的时候确保有足够的锁有效期窗口，当然如果业务本身提供回滚机制的话，那么方案就更加完备，该方案也在存储产品使用分布式锁的过程中被采用。不过，我们还要继续探讨我们认为的最佳方案：存储系统本身引入 IO Fence 能力。这里就不得不提 Martin Kleppmann 和 redis 的作者 antirez 之间的讨论了，redis 为了防止异步复制导致的锁丢失的问题，引入了 redlock ，该方案引入了多数派的机制，需要获得多数派的锁，最大程度的保证了可用性和正确性，但仍然有两个问题：

• 墙上时间的不可靠（ NTP 时间）
• 异构系统的无法做到严格正确性

墙上时间可以通过非墙上时间 Monotonic 来解决（ redis 目前仍然依赖墙上时间），但是异构的设计的只依靠单个系统无法保证完全正确，如下图七所示，Client1 获取了锁，在操作数据的时候发生了 GC ，在 GC 完成时候丢失了锁的所有权，造成了数据不一致。

因此我们需要两个系统同时协作来完成一个完全正确的互斥访问，在存储系统引入 IO Fence 能力，如下图所示，全局锁服务提供全局自增的 token ，Client1 拿到锁返回的 token 是 33 ，并带入存储系统，发生 GC ，当Client2 抢锁成功返回 34 ，带入存储系统，存储系统会拒绝 token 较小的请求，那么经过了长时间full gc重新恢复后的 Client 1 再次写入数据的时候，因为存储层记录的 Token 已经更新，携带 token 值为 33 的请求将被直接拒绝，从而达到了数据保护的效果（ chubby 的论文中有讲述，也是 Martin Kleppmann 提出的解决方案）。