Redis集群的历史

Redis在3.0前一般有两种集群方案，一是proxy（Twemproxy、Codis），二是使用Sentinel(哨兵）。通过Sentinel是一种使用哨兵来达到高可用的方案，而proxy是用于在前置上进行sharding用代理给后端的redis集群的方案，达到负载均衡的方案，在单个分片的redis中作主从。因为本文要重点讲解的不是3.0前的方案，因此说的比较粗略。

Redis3.0提供了官方的Redis cluster机制支持。主要通过内部无中心的多个节点来达到集群、高可用的作用。下面是Redis Cluster的架构图：

Redis Cluster的重要机制

sharding由Redis cluster根据client调用redis的key进行hash取模得到一个code，根据这个code放到16384个slot中。在以上的架构图中slot1组、slot2组、slot3组服务器中分别是对应的差不多1/3的slot。这样就得到了根据key的shading。
说到sharding就会说到怎么进行扩容和缩容，redis cluster也提供了工具进行迁移。不过由于不是一致性hash，所以涉及到迁移数据的节点数会多于一致性hash，但是迁移的量还是可控的，只会迁移部分以达到平均的效果。（redis cluster迁移详细机制需要另外详细研究）
在redis cluster的一个slot组中，采用的是主备的高可用模式，只有master对外提供服务，如果master挂掉，则slave会成为新的master，由新的master提供服务，在切换的过程中会在短时间的redis服务不可用。
redis cluster进入fail状态的条件：
- 如果同时有大于N（N为总slot组数）*1/2的master节点数同时挂掉，则cluster进入fail状态，因为剩下的master已经无法选出新的master节点了。分布式系统中必须要有大于N（N为总slot组数）*1/2的节点存在才能判断有效。节如果有是3主3备的集群，如果同时有2个master节点挂掉了，那么集群就挂掉了。
- 如果一个slot组中的服务器已经没有备用服务器了，这时master挂掉后，redis cluster也会进入fail状态。因为部分slot的数据已经查询不到了。
redis cluster具备高可用、sharding、负载均衡的功能。
如果多个key想要人为控制落到一个slot组上，可以通过对key进行改造实施。即如果key都以{key_pre}idxxxx这样，那么所有的key将是以key_pre去确定slot组，这样就达到了以{key_pre}开头的key都会是在一个slot组。
当向一个master中写入数据时，数据是进行迅速返回的，返回后再进行主从同步的方式向slave进行同步，因此这里是损失了CAP中的一致性的。在将来的redis版本中可能会开放同步写的方式写入slave，以维护一致性，当然这样会损失一定的写入速度。
在上文中提到的在做主从切换的时候，会有短时的不可用状态，因此会操作分布式理论CAP中可用性。
单个redis服务器上的请求是顺序执行的，因为redis服务器是单进程、单线程的。

分布式锁

分布式锁有很多的实现方案，通常有数据库、文件系统、zookeeper、redis。下面讲述基于redis cluster的分布式锁方案。

基于redis事务实现

严格来说这并不是分布式锁，只是通过改造可以实现锁的效果。这里并不是实现锁定其他的线程被阻塞的效果，而是如果数据被其他客户端修改了就返回失败。原理是基于reids的multi和watch命令。在事务开始前对要锁到的数据进行watch，进行业务操作后，如果发现锁定的数据已经变了，就提交失败，重新进行业务操作。在这个方案中如果执行失败就一直反复执行直到成功，也是实现了多个redis客户同时修改一个数据时的协调的锁的功能。

伪代码如下：

jedis.set("balance", String.valueOf(balance));

jedis.watch("balance");

Transaction transaction = jedis.multi();

transaction.decrBy("balance",amtToSubtract);/

transaction.incrBy("debt", amtToSubtract);

List result = transaction.exec();//执行事务

if(result == null){

//重新执行事务或者其他。

}else{

//事务执行成功。

}

基于setNX EX实现

Redis set key 时的一个 NX 参数可以保证在这个 key 不存在的情况下写入成功。并且再加上 EX 参数可以让该 key 在超时之后自动删除。

jedis伪代码：

String set(String key, String value, String nxxx, String expx,longtime);

为什么要以一代代码一个命令去实现呢，是因为要防止NX后突然就宕机了会产生死锁。

过期的时间的设置上要考虑几个问题：

如果时间设置比较长，如果锁定发起server发生宕机，那么很久都解锁不了。
如果时间设置比较短，可能会发生业务还没有做完，发生了解锁，没有起到锁定的作用。

关于解锁：在解锁时需要判断当前的锁是不是自己所锁定的，因此需要在加锁时将key的value设置为一个随机数，在解锁时进行判断。因为在解锁时有get数据再判断的多个操作，因此这里也需要防止并发问题，因此使用lua脚本写这个操作。如以下伪代码：

 $script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

    $result = $this->redis->eval(script,array($key,$val),1);

注意一个可能发生的问题:

redis的主从异步复制机制可能丢失数据，会出现如下场景：A线程获得了锁，但锁数据还未同步到slave上，master挂了，slave顶成主，线程B尝试加锁，仍然能够成功，造成A、B两个线程并发访问同一个资源。

基于lua脚本实现

由于redis服务器的单进程单线程模型，因此产生这种被大量使用的分布式锁的方案。

lua脚本通过eval或者evalsha方法进行执行，同时将脚本涉及到的key和参数传递给redis服务器执行。客户端可以通过jedis进行调用。 evalsha是对脚本在redis服务器进行预编译，这样可以减少网络交互量，加速执行时的速度。

注意以下：

由于是分布式集群环境，如果传递了多个key，而key处于不同的slot组服务器，那么执行将会报错。
lua脚本中由于是单进程单线程执行，因此不要做消耗时间的操作。在简单操作的情况下，在CPU 6核 Intel® Core™ i7-2720QM CPU @ 2.20GHz 内存16GB的情况下能跑出5万TPS。
如果要进行TPS扩容，则需要通过key对应的slot组不同，将lua分发到不同的slot组中的redis master服务器去执行。
程序都建议使用evalsha的方法去执行，这样可以提高TPS。

API网关分布式限流

API网关中针对一个API、API分组、接入应用APP ID,IP等进行限流。这些限流条件都将会产生一个限流使用的key，在后续的限流中都是对这个key进行限流。

限流算法通常在API网关中可以采用令牌桶算法实现。

必须说明一点的是分布式限流由于有网络的开销，TPS的支持隔本地限流是有差距的，因此在对于TPS要求很高的场景，建议采用本地限流进行处理。

下面讨论我们应该采用redis的哪一种分布式锁的方案：

由于redis事务要得到锁的效果需要在高TPS时会产生大量的无效的访问请求，所以不建议在这种场景下使用。

SET NX/EX的锁方案会产生在过期时间的问题，同时也有异步复制master数据到slave的问题。相比lua方案会产生更多的不稳定性。

我建议采用lua的方案来实施分布式锁，因为都是单进程单线程的执行，因此在TPS上和第二种方案没有大的区别，而且由于只是一个lua脚本在执行，甚至是可能纯lua执行可能会有更高的TPS。当然是lua脚本中可能还是会去设置过期时间，但是应用server宕机并不会影响到redis中的锁。当然master异步复制的问题还是有，但是并不会造成问题，因为数据只会有1个lua脚本执行问题，下一个执行就正常了。

在实现方案的时候使用了Jedis库，有一些问题在方案的实现层面我已经去做过验证了，可能也会是读者的疑问。

理论上jedis都应该是连接redis集群中的master节点，因为redis主备是采用的主备（Active-Standby方式）的方式。需要确定在这种情况下应该是配置所有的redis节点还是只配置master。理论上是需要配置所有的节点。

答：配置所有节点，做自动转发。

需要测试在其中一个slot组的master挂掉后，slave成为master后，jedis cluster的方式还能正常的访问对应的key。从资料上来看是能自动处理的。

答：能自动处理。

因为是采用redis cluster，所以需要测试key存储在slot 1组上时，jedis cluster连接的是slot 2组上的redis服务器，在这种情况下要能正常的调用lua。如果不能要看怎么样调用，因为redis可能会返回"MOVED"指令，这个要看jedis组件有没有实现自动的迁移。

答：能自动处理。

需要测试连接的是salve节点，但是读请求是转给了master节点，salve节点不处理请求。因为是主备（Active-Standby方式）状态。

答：能自动处理，由Jedis jar进行维护节点的状态，查询最新的master节点的信息。

有兴趣的朋友可以加入 QQ 交流群：244054462，备注：API 网关架构设计交流。

作者简介

颜诗超，成都小豹科技的“小豹API网关”产品负责人。

创作场景

Redis 集群分布式锁与 API 网关分布式限流