Redis分布式方案及一致性Hash算法精讲

 

为什么Redis需要分布式

高性能

我们知道Redis本身的QPS已经很高了，但是在一些并发量非常高的情况下，性能还是会受到影响的。这个时候我们希望更多的Redis服务来分摊压力，实现负载均衡。

高可用

如果只有一个Redis服务，一但服务发生了宕机，那么所有的客户端都无法访问，会对业务造成很大的影响。另外，如果硬件损坏了，那上面的所有数据也是无法恢复的，我们需要个备份。

可扩展

第三点是出于存储的考虑，因为redis所有的数据都放在内存中，如果数据量大，很容易收到硬件的限制。比如一台Redis只能存4G的容量，但是有8G的数据要存，所以只能放两台机器，这个就是横向扩展，水平分片。

Redis分布式方案

主从复制

跟Kafka、RocketMQ、MySQL、ZooKeeper一样，Redis支持集群的架构，集群的节点有主节点和从节点之分。主节点叫master，从节点叫slave。slave会通过复制的技术，自动同步master的数据。

Redis主从复制解决了数据备份和一部分性能的问题。但是没有解决高可用的问题，在一主一从或者一主多从的情况下，如果主服务器挂了，对外提供的服务就不可用了，需要手动把从服务器切换成主服务器，然后再把剩余节点设置为它的从节点，这个比较费时，还会造成一定时间的服务不可用。

Sentinel哨兵

从Redis2.8版本起，提供了一个稳定版本的Sentinel哨兵来解决高可用的问题，它的思路是启动奇数个Sentinel的服务来监控Redis服务器来保证服务的可用性。

启动Sentinel可用用脚本启动，它本质上只是一个运行在特殊模式之下的Redis。Sentinel通过info命令得到被监听Redis机器的master，slave等信息。

./redis-sentinel ../sentinel.conf
# 或者
./redis-server ../sentinel.conf --sentinel

为了保证监控服务器的可用性，我们会对Sentinel做集群部署，Sentinel既监控所有的Redis服务，Sentinel之间也相互监控。 Sentinel本身没有主从之分，地位是平等的，只有Redis服务节点有主从之分。

Sentinel通过Raft共识算法，实现Sentinel选举，选举出一个leader来，由leader完成故障转移。Raft算法的应用很广泛，比如加密货币BTB，Spring Cloud注册中心Consul也用到了Raft算法。Raft算法的核心思想是：先到先得，少数服从多数。Sentinel的Raft实现跟原生的算法是有所区别的，但是大体思想一致。 Raft算法演示：thesecretlivesofdata.com/raft/ 。

无论Jedis还是Spring Boot（2.x版本默认是Lettuce），都只需要配置全部的哨兵地址，由哨兵返回当前的master节点地址。

哨兵的不足：主从切换的过程中会丢失数据，因为只有一个ma