干货！带你了解为什么那么多开源项目都是用Redis!( 二 ) 很多开源项目中都使用了redi

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master ，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。
（2）工作机制：
每个Sentinel（哨兵）进程以每秒钟一次的频率向整个redis集群中的master主服务器、slave从服务器以及其他的Sentinel（哨兵）进程发送一个ping命令。
如果一个实例距离最后一次有效回复ping命令的时间超过down-after-milliseconds选项所指定的值则这个实例会被Sentinel标记为主观下线（SDOWN）。
如是是master主服务器被标记为SDOWN ，则正在监控这个服务器的所有Sentinel都要以每秒一次的频率确认服务器是否真的已经进入SDOWN(主观下线状态) 。
当有足够数量（≥配置文件配置值）的Sentinel在指定的时间内确认了master进入了SDOWN状态，则master被标记为ODOWN(客观下线状态) 。
在一般情况下，每个Sentinel会每10秒向redis主服务器和从服务器发送Info命令。但是当master被标记为客观下线时，频率改为1秒一次。
若没有足够数量的Sentinel同意master服务器下线，则master的SDOWN状态被移除，若master重新向Sentinel发送ping命令返回了有效回复，则master的SDOWN状态被移除。
（3）优缺点
优点：哨兵集群，基于主从复制模式，所有的主从配置优点，它都有主从可以切换，故障可以转移，高可用性的系统哨兵模式就是主从模式的升级，手动到自动，更加健壮；
缺点：Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦，哨兵模式的配置繁琐；
3、集群（Cluster）

文章图片
（1）模式来源：
sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。单台服务器资源的总是有上限的， CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上。但是内存资源怎么办，主从模式做到的只是相同数据的备份，并不能横向扩充内存；单台机器的内存也只能进行加大处理，但是总有上限的。所以我们就需要一种解决方案，可以让我们横向扩展。 cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。
cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。
使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。还有就是客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
（2）工作机制：
在redis的每一个节点上，有两样东西我们比较关注，一个是插槽（slot），它的取值范围是：0~16383 。还有一个就是cluster ，它类似是一个集群管理的插件。当我们的存取的key到达的时候， redis会根据特定的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
RedisCluster一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群，其中三个为主节点，三个为从节点。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。
（3）优缺点
优点：无中心架构，数据按照slot分布在多个节点；
集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据；