Redis集群设计原理

---恢复内容开始---

Redis集群设计包括2部分：哈希Slot和节点主从，本篇博文经过3张图来搞明白Redis的集群设计。

 

节点主从：

主从设计不算什么新鲜玩意，在数据库中咱们也常常用主历来作读写分离，直接上图：

 

 

图上能看获得的信息：

1， 只有1个Master，能够有N个slaver，并且Slaver也能够有本身的Slaver，因为这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。

2， 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，因此Slaver的扩容只能提升读效率不能提升写效率。

3， Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，因此Redis是内存数据库。

当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，因此尽可能避免在运行时作Slaver的扩容。

简单总结下主从模式的设计：

优势：读写分离，经过增长Slaver能够提升并发读的能力。

缺点：Master写能力是瓶颈。

          虽然理论上对Slaver没有限制可是维护Slaver开销总将会变成瓶颈。

          Master的Disk大小也将会成为整个Redis集群存储容量的瓶颈。

 

哈希Slot：

这个艺名看起来很文艺，但也不是什么新技术，他的真名就叫分表分库，再上一个图：

图上能看到的信息：

1， 对象保存到Redis以前先通过CRC16哈希到一个指定的Node上，例如Object4最终Hash到了Node1上。

2， 每一个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，不然会致使对象重复存储或没法存储。

3， Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位作数据的迁移。例如Node1若是掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,因为Node2和Node3自己维护的Slot还会在本身身上不会被从新分配，因此迁移过程当中不会影响到5641-16384Slot段的使用。

简单总结下哈希Slot的优缺点：

缺点：每一个Node承担着互相监听、高并发数据写入、高并发数据读出，工做任务繁重

优势：将Redis的写操做分摊到了多个节点上，提升写的并发能力，扩容简单。

双剑合并：

看到这里你们也就发现了，主从和哈希的设计优缺点正好是相互弥补的，将图一每一套主从对应到图二中的每个Node，就是Redis集群的终极形态，先Hash分逻辑节点，而后每一个逻辑节点内部是主从，如图：

想扩展并发读就添加Slaver，想扩展并发写就添加Master，想扩容也就是添加Master，任何一个Slaver或者几个Master挂了都不会是灾难性的故障。

---恢复内容结束---