前言
在项目中我们经常有需要使用分布式锁的场景，而Redis是实现分布式锁最常见的一种方式，这篇文章主要是使用Go+Redis实现互斥锁和红锁。
下面的代码使用go-redis客户端和gofakeit库。
代码地址
互斥锁
设置如果不存在SET resource_name my_random_value NX PX 30000resource_nameNXPX 30000my_random_value值必须是随机数主要是为了更安全的释放锁，释放锁的时候使用脚本告诉Redis：只有key存在并且存储的值和我指定的值一样才能告诉我删除成功，避免错误释放别的竞争者的锁。
由于涉及到两个操作，因此我们需要通过Lua脚本保证操作的原子性：
举个不用Lua脚本的例子：客户端A取得资源锁，但是紧接着被一个其他操作阻塞了，当客户端A运行完毕其他操作后要释放锁时，原来的锁早已超时并且被Redis自动释放，并且在这期间资源锁又被客户端B再次获取到。
因为判断和删除是两个操作，所以有可能A刚判断完锁就过期自动释放了，然后B就获取到了锁，然后A又调用了Del，导致把B的锁给释放了。
TryLock和Unlock实现
TryLockSET resource_name my_random_value NX PX 30000UUIDUnlockUnlocklua脚本Lock实现
Lockerror步骤如下：
- 尝试加锁，加锁成功直接返回
- 加锁失败则不断循环尝试加锁直到成功或出现异常情况
实现看门狗机制
我们前面的例子中提到的互斥锁有一个小问题，就是如果持有锁客户端A被阻塞，那么A的锁可能会超时被自动释放，导致客户端B提前获取到锁。
为了减少这种情况的发生，我们可以在A持有锁期间，不断地延长锁的过期时间，减少客户端B提前获取到锁的情况，这就是看门狗机制。
当然，这没办法完全避免上述情况的发生，因为如果客户端A获取锁之后，刚好与Redis的连接关闭了，这时候也就没办法延长超时时间了。
看门狗实现
加锁成功时启动一个线程，不断地延长锁地过期时间；在Unlock时关闭看门狗线程。
看门狗流程如下：
- 加锁成功，启动看门狗
- 看门狗线程不断延长锁的过程时间
- 解锁，关闭看门狗
TryLock：启动看门狗
Unlock：关闭看门狗
红锁
由于上面的实现是基于单Redis实例，如果这个唯一的实例挂了，那么所有请求都会因为拿不到锁而失败，为了提高容错性，我们可以使用多个分布在不同机器上的Redis实例，并且只要拿到其中大多数节点的锁就能加锁成功，这就是红锁算法。它其实也是基于上面的单实例算法的，只是我们需要同时对多个Redis实例获取锁。
加锁实现
SET resource_name my_random_value NX PX 30000channelsync.WaitGroup然后判断成功获取到的锁的数量是否大于一半，如果没有得到一半以上的锁，说明加锁失败，释放已经获得的锁。
如果加锁成功，则启动看门狗延长锁的过期时间。
看门狗实现
我们需要延长所有成功获取到的锁的过期时间。
解锁实现
我们需要解锁所有成功获取到的锁。