Redis学习 master/slave(主从)、sentinel(哨兵)、Cluster简单总结

一.主从模式（master/slaver）

Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构。

对主从模式的理解：

1. 一个Master可以有多个Slaves
2. 默认配置下，master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止
3. 不要修改配置让slave节点支持写操作，没有意义，原因一，写入的数据不会被同步到其他节点；原因二，当master节点修改同一条数据后，slave节点的数据会被覆盖掉
4. slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来
5. master节点挂了以后，不影响slave节点的读，Redis将不再提供写服务，master节点启动后Redis将重新对外提供写服务。
6. master节点挂了以后，slave节点不会再选一个master

优点：

1. 数据备份
2. 负载均衡，所有客户端都访问一个节点肯定会影响Redis工作效率，有了主从以后，查询操作就可以通过查询从节点来完成写入操作可以通过主节点来完成
3. 做到读写分离（master 写入，slave 读取），提高服务器性能

缺点：

1. master节点挂了以后，redis就不能对外提供写服务了，因为剩下的slave不能成为master

这个缺点影响是很大的，尤其是对生产环境来说，是一刻都不能停止服务的，所以一般的生产坏境是不会单单只有主从模式的。所以有了下面的sentinel模式。

二.哨兵(sentinel)

sentinel的中文含义是哨兵、守卫。也就是说既然主从模式中，当master节点挂了以后，slave节点不能主动选举一个master节点出来，那么我就安排一个或多个sentinel来做这件事，当sentinel发现master节点挂了以后，sentinel就会从slave中重新选举一个master。

Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

例如：

在service1 掉线后：

升级Server2 为新的主服务器：

对sentinel的理解：

1. sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义
2. 当master节点挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master
3. 当master节点重新启动后，它将不再是master而是做为slave接收新的master节点的同步数据
4. sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群
5. 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不许要担心。
6. 一个sentinel或sentinel集群可以管理多个主从Redis。
7. sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了
8. sentinel监控的Redis集群都会定义一个master名字，这个名字代表Redis集群的master Redis。

优点

1. Master 状态监测
2. 如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave

缺点：

1. 如果是从节点下线了，sentinel是不会对其进行故障转移的，连接从节点的客户端也无法获取到新的可用从节点

2. 无法实现动态扩容

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中，就是下面要讲的。

三.Cluster

3.1 cluster的出现是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。cluster可以说是sentinel和主从模式的结合体

3.2 先来一张redis 集群的架构图：

在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

一般集群建议搭建三主三从架构，三主提供服务，三从提供备份功能。

每一个节点都存有这个集群所有主节点以及从节点的信息。

3.3 cluster工作原理图：

1. 它们之间通过互相的ping-pong判断是否节点可以连接上。
2. 如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。
3. 如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入fail状态。
4. 这就是我们的redis的投票机制

3.4 其结构特点：

1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2. 节点的fail是通过集群中超过半数的节点检测失效时才生效。
3. 客户端与redis节点直连,不需要中间proxy层。客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4. **redis-cluster把所有的redis节点映射到[0-16383]slot上（不一定是平均分配）,**当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到redis节点里。

这种模式适合数据量巨大的缓存要求，当数据量不是很大使用sentinel即可。