Redis集群部署

redis是由意大利的一家创业公司Merzia的创始人Salvatore Sanfilippo(antirez是他的艺名)在2008年根据公司需求所开发的一个开源的高性能键值对数据库，于2009开发完成，并于当年随即开源了redis。2010年VMware公司开始赞助redis开发，Salvatore Sanfilippo和Pieter Noordhuis也于同年3月和5月加入VMware，全职开发redis。

redis是（Remote Dictionary Server(远程字典服务器)）的缩写，它以字典结构存储数据，并允许其他应用通过TCP协议读写字典中的内容。redis官方提供的集群方案是慢慢发展起来的，早期只有主从复制，后来有了哨兵模式，再后来有了cluster模式，我们先来看看redis历史版本的情况，目前能下载到的最早版本为redis-2.6.14，各个版本情况如下：

2009年0.0.1

2011年发布2.0，已经支持replication复制了

2012年发布2.6，redis sentinel第一版

2013年发布2.8，redis sentinel第二版

2015年发布3.0.0(里程碑版本),开始支持redis cluster功能

2016年发布3.2.0

2017年发布4.0.0

2018年发布5.0.0

可以看到，主从复制是最早的提供的高可用解决方案，然后是sentinel方案，最后有了cluster集群方案，我们目前肯定会选用cluster方案。也可以从侧面看出，主从复制是个很基本的手段，这个在传统数据库中也是很常见的，比如MySQL中。

主从复制

先来说主从复制，redis支持一主多从，从节点可以继续拥有从节点形成链式复制关系，一个从节点只能拥有一个主节点。主从复制由从节点发起，主节点不用做任何处理，数据只能由主节点发送到从节点，主从复制是高可用的基础手段。
主从复制的作用：
1、数据备份：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4、读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
5、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
开启主从复制方式：
1、配置文件： 在从服务器的配置文件中加入：slaveof <masterip> <masterport>
2、启动命令： redis-server启动命令后加入 --slaveof <masterip> <masterport>
3、客户端命令： Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该redis实例成为从节点。

sentinel模式

sentinel是用来监控所有节点的，当发现master不可用后，sentinel会选举这个master下的某一个slave为新的master，集群中的slaves会自动指向新的master同步数据，从而继续提供服务，所以，sentinel模式一定要使用主从复制。另外我们需要了解sentinel节点与sentinel节点，sentinel节点与redis节点之间是如何通信的。一般情况下，sentinel节点会和redis节点建立2条连接，一条是命令连接，一条是订阅连接。sentinel通过向master发送 INFO 命令来自动获得所有slaves的地址，跟master一样，sentinel 会与每个被发现的slave创建命令连接和订阅连接，这样以后，sentinel就获得了所有监控的redis节点信息。另外，sentinel 会通过命令连接向被监视的主从服务器发送 HELLO 信息，该消息包含 sentinel 的 IP、端口号、ID 等内容，以此来向其他 sentinel 宣告自己的存在。与此同时，Sentinel 会通过订阅连接接收其他 sentinel 的HELLO 信息，以此来发现监视同一个master的其他 sentinel，这样以后，所有sentinel之间就建立了通信。sentinel 之间会互相创建命令连接，用于进行通信。因为已经有redis主从节点作为发送和接收 HELLO 信息的中介，所以 sentinel之间不会创建订阅连接。

sentinel 使用 PING 命令来检测实例的状态：如果实例在指定的时间内没有返回回复，或者返回错误的回复，那么该实例会被 sentinel 判断为SDOWN（subjectively down,主观下线）。
注意：只有一台Sentinel将服务器标记为SDOWN不会触发Failover。只有一定数量的Sentinel都将该服务器标记为SDOWN后，服务器才会被标记为ODOWN（objectively down，客观下线），这时才会触发Failover过程。
参数down-after-milliseconds指定了 Sentinel 认为服务器已经断线所需的毫秒数。
参数quorum用来控制Sentinel投票数。在下线Master的所有Slave中，选出一个数据状态最接近Master的Slave，选择的条件包括：Slave未下线、主从之间的连接断开时间最短，等等。
Sentinel 向被选中的Slave发送 SLAVEOF NO ONE ，将它升级为Master。
向其他Slave发送 SLAVEOF 命令，让它们复制新的Master。

sentinel通过配置发现redis主节点，比如需要监听多个redis主节点：

sentinel monitor mymaster1 172.18.1.101 7001 2
sentinel monitor mymaster2 172.18.1.102 7002 2
sentinel monitor mymaster3 172.18.1.103 7003 2

sentinel down-after-milliseconds mymaster1 10000
sentinel down-after-milliseconds mymaster2 10000
sentinel down-after-milliseconds mymaster3 10000

sentinel parallel-syncs mymaster1 1
sentinel parallel-syncs mymaster2 1
sentinel parallel-syncs mymaster3 1

sentinel failover-timeout mymaster1 15000
sentinel failover-timeout mymaster2 15000
sentinel failover-timeout mymaster3 15000

cluster模式

主从复制模式只是一个集群，主从节点上的数据都一样，无法满足分布式缓存的需求，所以我们需要使用cluster方案。在分布式缓存设计上，redis没有使用一致性哈希算法，直接使用了哈希槽的方式，作者认为这个方案和一致性哈希算法效果类似，且实现起来更简单，所以就使用这个方案。redis cluster定义了16384个逻辑槽位，每个master负责其中一部分槽位，当需要存储值时，通过HASH_SLOT = CRC16(key) mod 16384得出槽位号，就知道去哪个节点存储数据了。这里需要解释的是，每个master维护着一个各不相同的16384位序列（也即长度为2048的byte数组），这个结构就能快速判断某个槽位是否由当前master负责，然后还有一个槽号的索引数组，长度为16384，下标表示槽号，值表示master节点，这样就能快速找到槽号对应的master节点。