redis cluster是如何做到集两家之长的

站在读写分离的层次看redis的时候，redis和master和slave存在明显的主从关系，也就是说master处于管理状态，salve跟着大哥混，master给小弟slave发粮食【发送内存快照数据】；然后

平时写的时候需要大哥来做，但是数据量很大的时候大哥会经常吃不消，读的时候小弟来提供服务，小弟可以随便招，扩容比较方便；这就是典型的主从节点结构：

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

图上能看得到的信息：

1， 只有1个Master，可以有N个slaver，而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。

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

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

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

优点：读写分离，通过增加Slaver可以提高并发读的能力。

缺点：Master写能力是瓶颈【致命的不足】。

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

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

后边就发展出了slot结构，该种结构就是分区了，写入的东西需要经过计算存放在对应的区域，读的时候也要去对应的分区读，其实很想集合框架中的HashMap结构；

哈希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挂了都不会是灾难性的故障。