Day 7 Redis Lock

Day 7 Redis Lock

The best way to predict the future is to invent it——Alan Kay（Smalltalk之父）

The simplest way to use Redis to lock a resource is to create a key in an instance.
要想使用Redis对一个资源上锁，最简单的办法是在一个Redis实例中建立一个键。

The key is usually created with a limited time to live, using the Redis expires feature, so that eventually it will get released. When the client needs to release the resource, it deletes the key.
在新建一个“键”时，通常会使用redis的过期机制，给它加上有限的生存时间，以保证这个“键”最终一定会被删除掉。如果客户端想要释放资源锁，它也可以自己删除这个键。

Superficially this works well, but there is a problem: this is a single point of failure in our architecture.
表面上来看，这个办法行之有效。但其实这里有个问题：这是我们架构中的单点故障隐患。

What happens if the Redis master goes down? Well, let’s add a slave! And use it if the master is unavailable. This is unfortunately not viable.
如果Redis主服务宕机了怎么办呢？那我们就加个“从服务器”吧！主服务器不行了就用它顶上。然而不幸的是，这不是一种可行的做法。

By doing so we can’t implement our safety property of mutual exclusion, because Redis replication is asynchronous.
如果我们那么做的话，我们就无法实现互斥的安全性了——因为redis的replication机制是异步的。

There is an obvious race condition with this model:
这个模型会有一个明显的竞争条件：

Client A acquires the lock in the master.
客户端A获得了Redis主服务器上的锁。

The master crashes before the write to the key is transmitted to the slave.
在主服务器上的锁还没来得及传递给从服务器的时候，主服务器就出现故障了。

The slave gets promoted to master.
从服务器被提升为主服务器。

Client B acquires the lock to the same resource A already holds a lock for. This is safety violation!
客户端B获得了已经被客户端A上锁的资源。这违反了安全性。

本文选自：
https://redis.io/topics/distlock