“Redis用过吗?”
“用过。”
“能谈谈对Redis集群的认识吗?”
“额……”
这是一段真实的面试经历。
最近，各大互联网公司都开始了裁员，导致大量互联网从业人员又开始了艰辛的求职路。老手自不必说，但对于久在项目里但基本只是使用Redis的程序员们来说，估计这问题得难倒一部分人。
Redis集群方式共有三种：主从模式，哨兵模式，cluster(集群)模式。下面我们来一起看卡这三种模式分别是如何工作的吧。
主从模式
主从模式是三种集群方式里最简单的。它主要是基于Redis的主从复制特性架构的。通常我们会设置一个主节点，N个从节点。
默认情况下，主节点负责处理使用者的IO操作，而从节点则会对主节点的数据进行备份，并且也会对外提供读操作的处理。这样做有两个目的：备份数据，负载均衡。
备份数据
主从模式下，当某一节点损坏时，因为其会将数据备份到其它Redis实例上，这样做在很大程度上可以恢复丢失的数据。
负载均衡
主从模式下，主节点和从节点是读写分离的。使用者不仅可以从主节点上读取数据，还可以很方便的从从节点上读取到数据，这在一定程度上缓解了主机的压力。
当然，从节点也是能够支持写入数据的，只不过从从节点写入的数据不会同步到主节点以及其它的从节点下。
从以上，我们不难看出Redis在主从模式下，必须保证主节点不会宕机——一旦主节点宕机，其它节点不会竞争称为主节点，此时，Redis将丧失写的能力。这点在生产环境中，是致命的。所以Redis为我们引入了另一种集群模式——哨兵模式。
哨兵模式
哨兵模式是基于主从模式做的一定变化，它能够为Redis提供了高可用性。在实际生产中，服务器难免不会遇到一些突发状况：服务器宕机，停电，硬件损坏等。这些情况一旦发生，其后果往往是不可估量的。而哨兵模式在一定程度上能够帮我们规避掉这些意外导致的灾难性后果。
其实，哨兵模式的核心还是主从复制。只不过相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制——从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。
sentinel特点
- 监控
- 它会监听主服务器和从服务器之间是否在正常工作。
- 通知
- 它能够通过API告诉系统管理员或者程序，集群中某个实例出了问题。
- 故障转移
- 它在主节点出了问题的情况下，会在所有的从节点中竞选出一个节点，并将其作为新的主节点。
- 提供主服务器地址
- 它还能够向使用者提供当前主节点的地址。这在故障转移后，使用者不用做任何修改就可以知道当前主节点地址。
就sentinel而言，其当然也具备一定集群能力，Redis sentinel本身就是一个分布式系统。但sentinel集群，和其他的集群有点不一样。sentinel可以通过发布与订阅来自动发现Redis集群上的其它sentinel。sentinel在发现其它sentinel进程后，会将其放入一个列表中，这个列表存储了所有已被发现的sentinel。
集群中的所有sentinel不会并发着去对同一个主节点进行故障转移。故障转移只会从第一个sentinel开始，当第一个故障转移失败后，才会尝试下一个。当选择一个从节点作为新的主节点后，故障转移即成功了(而不会等到所有的从节点配置了新的主节点后)。这过程中，如果重启了旧的主节点，那么就会出现无主节点的情况，这种情况下，只能重启集群。
当竞选出新的主节点后，被选为新的主节点的从节点的配置信息会被sentinel改写为旧的主节点的配置信息。完成改写后，再将新主节点的配置广播给所有的从节点。
Cluster(集群)模式
Cluster(集群)模式的出现是为了解决Redis单机容量有限的问题的。该种模式会将Redis中数据按照一定规则划分到多台机器上。这种模式有两个特点：
能够在多个节点之间自动拆分数据集。
当节点的子集遇到故障或无法与群集的其余部分通信时，能够继续操作。
Redis集群中有16384个散列槽。而Redis群集中的每个节点只负责哈希槽的一个子集。
例如，您可能拥有一个包含3个节点的集群，其中：
- 节点A包含从0到5500的散列槽。
- 节点B包含从5501到11000的散列槽。
- 节点C包含从11001到16383的散列槽。
这允许使用者轻松添加和删除集群中的节点。例如，如果我想添加一个新节点D，我需要将一些哈希槽从节点A，B，C移动到D.同样，如果我想从群集中删除节点A，我只需移动A服务的哈希槽。到B和C.当节点A为空时，我可以完全从集群中删除它。
因为将哈希槽从一个节点移动到另一个节点不需要停止操作，添加和删除节点，或者更改节点所持有的哈希槽的百分比，所以不需要任何停机时间。
