Redis集群的一些思考

序

站在初学者的角度，一步一个脚印的去考虑怎么做好Redis的集群。

为什么要集群。

1：可以提高吞吐量。
2：可以提高可用性。
3：提高Redis的容量。

集群方案1

**特点：**如上图所示数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。slave 订阅 master，master定时把数据同步到slave。

同步流程如下图所示:

1、Slave服务器发起同步求请（slaveof）
2、Master创建快照。
3、Slave载入快照。
4、持续增量同步。

提问：
Master挂掉了，会造成什么样的影响？

回答：
Master是写入的服务器，Master挂掉了，将导致写不进数据。所有的Slave的数据将停留在Master挂掉之前的状态。
需要人工手动切换指定Master，但这个处理的时效性不够。

集群方案2（优化1）

优化方案：
引入哨兵。监控Redis节点,当监控到Master失去连接后，对其它节点进行选举，然后把其中的一个节点设置为Master，其它节点向新的Master订阅。

提问：
哨兵也会有可能挂掉，怎么处理呢？

回答：
可以启动多个哨兵相互监控，整个框架如下如所示。
Redis高可用，哨兵也高可用。

提问：
因为是主从复制的，也就是说所有的Redis都存着相同的数据，那么容量的上限就是一台服务器的内存上限，如果数据超出内存上限怎么办？

回答：
可以采用Redis切片存储的方式解决这个问题 。

集群方案3（优化2）

方案：
1：可以准备多个Redis集群（每个都是独立的），对key进行hash得下标，然后决定存储在哪个Redis集群。
2：可以利用Nginx对key进行Hash,然后转发到对应的Redis集群。

**流程：**如下图所示。
1：客户端访问虚拟IP。
2：虚拟IP转向Nginx。
3：Nginx对接收的Key进行Hash，根据下标转向到对应的Redis集群。

现在看来，问题都解决了。每个环节都是高可用了，主从复制的数据容量局限性也得到解决。

提问：
假设Redis集群结点数从3扩容到7，需要做哪些动作，以及有什么影响呢？
回答:
配置：
1：nginx调整hash算法。
2：添加Redis集群。

影响：hash算法的调整，导致Redis的集群的数据失效，数据需要重新定向。
举个例子。原来的hash长度为2位，扩展之后hash长度为3位。原来Ox00下标的数据有可能会定向到Ox000，Ox100两台服务器。定向到Ox100服务器的，将查不到数据。
总结：
综合以上，扩容是挺不方便的。
杀手锏方案，Cluster将解决扩容难的问题。

集群方案3（全新方案-Cluster 集群）

Cluster介绍：
Cluster集群是Redis3.0之后推出的集群方案。解决了以上各种问题。
Cluster集群的特点:
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽
客户端与 Redis 节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

Cluster工作方式：
　　在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
　　为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

总结

我觉得Redis的集群方案主要还是根据实际的应用场景来决定。
如果数量不是很大的情况下，使用《集群方案2》就足够了。
如果数据量大，那就直接上Redis Cluster 集群方案。简单，扩展性好。