redis集群和哨兵的区别,redis哨兵和集群区别是什么？

redis集群和哨兵的区别,redis哨兵和集群区别是什么？详细介绍

本文目录一览： redis哨兵和集群区别是什么？

redis哨兵和集群的区别如下。
监控（Monitoring）：Sentinel会不断地检查你的主服务器和从服务器是否运作正常，提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
集群即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储。
即每台redis存储不同的内容，共有16384个slot。每个redis分得一些slot，hash_slot = crc16(key) mod 16384找到对应slot，键是可用键，如果有｛}则取｛}内的作为可用键，否则整个键是可用键。
主从、哨兵、集群各自架构的优点和缺点对比
优点：·架构简单，部署方使。高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务，高性能。
缺点：·不保证数据的可靠性。在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。
高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用Memcached替代。

redis哨兵和集群区别是什么？

redis哨兵和集群区别是：
监控主数据库和从数据库是否正常运行。
主数据库出现故障时自动将从数据库转换为主数据库。sentinel发现master挂了后，就会从slave中重新选举一个master。哨兵模式强调高可用。
Sentinel会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作。
它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器。
当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
客户端中不会记录redis的地址（某个IP），而是记录sentinel的地址，这样我们可以直接从sentinel获取的redis地址。
因为sentinel会对所有的master、slave进行监控，它是知道到底谁才是真正的master的，例如我们故障转移，这时候对于sentinel来说，master是变了的，然后通知客户端。
而客户端根本不用关心到底谁才是真正的master，只关心sentinel告知的master。
集群即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。
为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容，共有16384个slot。
每个redis分得一些slot，hash_slot = crc16(key) mod 16384找到对应slot，键是可用键，如果有｛｝则取｛｝内的作为可用键，否则整个键是可用键。
集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。
集群模式提高并发量。
Redis：Remote Dictionary Server ，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

Redis主从模式、哨兵模式以及Cluster 集群模式

主从模式指的是使用一个Redis实例作为主机，其余的实例作为备份机。一般来说主节点负责写请求，从节点负责读请求，主节点异步的同步给从节点。主节点和从节点保存的数据是相同的，但是因为同步，从节点的数据会有一点延迟。但是主从模式的高可用会有问题。因为主节点挂了之后是没有自动选主机制的，需要人工干预来指定一个从节点作为主节点。
为了解决主从模式不能高可用的问题，哨兵模式就出现了。哨兵模式就是在主从模式的基础上再加一个哨兵集群。每个哨兵都会监控主节点和从节点的状态。如果主节点挂了，就会从从节点中选出一个来作为主节点，以达到高可用的目的。（也就是有了自动选主机制）
哨兵集群中的每个节点都会启动三个定时任务
如果一个 实例（instance）距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线 。
如果一个 主服务器 被标记为主观下线，那么正在 监视 这个主服务器的所有 Sentinel 节点，要以 每秒一次的频率确认 该主服务器是否的确进入了主观下线状态。
如果一个主服务器 被标记为主观下线，并且有 足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的 时间范围 内同意这一判断，那么这个该主服务器被标记为 客观下线。 哨兵模式解决了故障不能自动恢复的问题，但仍存在的问题是：Redis较难支持在线扩容，对于集群，容量达到上限时在线 扩容会变得很复杂 。
Redis Cluster采用虚拟槽分区，所有的键按照哈希函数映射到0~16383槽中，每个Redis节点维护部分槽和槽中的数据。

玩转Redis的高可用（主从、哨兵、集群）

所谓的高可用，也叫 HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式： 主从模式 ， 哨兵模式和集群模式 。
Redis 提供了 Redis 提供了复制(replication)功能，当一台 redis 数据库中的数据发生了变化，这个变化会被自动地同步到其他的 redis 机器上去。
Redis 多机器部署时，这些机器节点会被分成两类，一类是主节点（master 节点），一类是从节点（slave 节点）。一般 主节点可以进行读、写操作 ，而 从节点只能进行读操作 。一个主节点可以有多个从节点，但是一个从节点只会有一个主节点，也就是所谓的 一主多从结构 。
· 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离;
· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求;
· Slave 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis 则返回同步之前的数据。
· Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复;
· 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后面还会引入数据不一致的问题，降低了系统的可用性;
· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂;
· Redis 的主节点和从节点中的数据是一样的，降低的内存的可用性

实际生产中，我们优先考虑哨兵模式。这种模式下，master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。
在主从模式下，redis 同时提供了哨兵命令 redis-sentinel ，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。一般为了便于决策选举，使用 奇数个哨兵 。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:
· 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器;
· 然而一个哨兵进程对 Redis 服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多种哨兵模式。
哨兵很像 kafka 集群中的 zookeeper 的功能。
· 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
· 主从可以自动切换，系统更健壮，可用性更高。
· 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。
· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法，而是使用 slots 插槽 。
Redis 哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0 上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容；每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。 通讯时使用特殊的端口号，即对外服务端口号加 10000。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

对客户端来说，整个 cluster 被看做是一个整体，客户端可以连接任意一个 node 进行操作，就像操作单一 Redis 实例一样， 当客户端操作的时候 key 没有分配到该 node 上时，Redis 会返回转向指令，指向正确的 node，这有点儿像浏览器页面的 302 redirect 跳转。
根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。
在 Redis 的每一个节点上，都有这么两个东西， 一个是插槽（slot），它的的取值范围是：0-16383， 可以从上面 redis-trib.rb 执行的结果看到这 16383 个 slot 在三个 master 上的分布。还有一个就是 cluster，可以理解为是一个集群管理的插件，类似的哨兵。
当我们的存取的 Key 到达的时候，Redis 会根据 crc16 的算法对计算后得出一个结果，然后把结果和 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
为了保证高可用， redis-cluster 集群引入了主从模式 ，一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时，如果半数以上的主节点与 master 1 通信超时，那么认为 master 1 宕机了，就会启用 master 1 的从节点 slave 1，将 slave 1 变成主节点继续提供服务。
如果 master 1 和它的从节点 slave 1 都宕机了，整个集群就会进入 fail 状态，因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉，无论是否有 slave，集群都会进入 fail 状态。
redis-cluster 采用去中心化的思想 ，没有中心节点的说法，客户端与 Redis 节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
对 redis 集群的扩容就是向集群中添加机器，缩容就是从集群中删除机器，并重新将 16383 个 slots 分配到集群中的节点上（数据迁移）。
扩缩容也是使用集群管理工具 redis-tri.rb。
扩容时，先使用 redis-tri.rb add-node 将新的机器加到集群中，这是新机器虽然已经在集群中了，但是没有分配 slots，依然是不起做用的。在使用 redis-tri.rb reshard 进行分片重哈希（数据迁移），将旧节点上的 slots 分配到新节点上后，新节点才能起作用。
缩容时，先要使用 redis-tri.rb reshard 移除的机器上的 slots，然后使用 redis-tri.rb add-del 移除机器。
采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;
可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;
高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;
降低运维成本，提高系统的扩展性和可用性。
1.Redis Cluster 是无中心节点的集群架构，依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG 通讯，不必须要的流量占用了大量的网络资源。虽然 Reds4.0 对此进行了优化，但这个问题仍然存在。
2.数据迁移问题
Redis Cluster 可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。
而 Redis 为了保证迁移的一致性，迁移所有操作都是同步操作 ，执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小 Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。
主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。
哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。
集群模式：数据量比较大，QPS 要求较高的时候使用。 Redis Cluster 是 Redis 3.0 以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

redis 有了集群还需要主从哨兵吗

主从哨兵是全量存储，集群是分布式存储，只使用集群的话，如果其中一台机器挂了，就会导致部分数据丢失，所以集群一般是多套主从结合使用
即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容，
共有16384个slot。每个redis分得一些slot，hash_slot = crc16(key) mod 16384 找到对应slot，键是可用键，如果有{}则取{}内的作为可用键，否则整个键是可用键
集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。
所以还是需要的，因为redis的集群是把内容存储到各个节点上，而哨兵的作用就是监控redis主、从数据库是否正常运行，主出现故障自动将从数据库转换为主数据库。

redis有哪些集群模式

Redis集群一般有5种：1，主从复制2，哨兵模式3，Redis官方提供的Cluster集群模式(服务端)4，Jedis sharding集群(客户端sharding)5,利用中间件代理，比如豌豆荚的codis等介绍完他们的模式，现在来分析一下他们的原理：主从复制（Master-Slave Replication）:实现主从复制（Master-Slave Replication）的工作原理：Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。主从复制配置修改从节点的配置文件：slaveof masterip masterport如果设置了密码，就要设置：masterauth master-password哨兵模式:该模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。Sentinel（哨兵）进程的作用监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。提醒(Notification)：当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。Sentinel（哨兵）进程的工作方式每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。Redis官方 Cluster集群模式Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。Redis集群数据分片在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。Jedis sharding集群Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式，其主要思想是采用hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。庆幸的是，Java Redis客户端驱动Jedis已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPoolJedis的Redis Sharding实现具有如下特点：采用一致性哈希算法，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。利用中间件代理中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。常用的中间件有这几种TwemproxyCodisnginx

Redis集群模式1-主从复制+哨兵机制

单个Redis服务如果宕机的话，服务就不可用了，为了解决这种问题，redis也提供有集群服务。传统的Redis集群采用的主从复制模式，一般为一主多从，主节点有读写权限，但是从节点只有读的权限。主节点会定期将数据同步到从节点中，保证数据一致性的问题。这种集群方式在运行时存在一些问题：
Redis的哨兵机制就是解决主从复制存在缺陷（选举问题），解决问题保证我们的Redis高可用，实现自动化故障发现与故障转移。 要使用哨兵机制，除了启动Redis服务以外，还要启动哨兵服务来进行监控，会介绍详细步骤。哨兵服务的工作原理如下：
演示集群采用1主2从，采用伪集群，在一台虚拟机中启动，端口暂定6381、6382、6383，集群结构可以选择下面2种，因为数量较少，此次采用普通样式。
主节点配置文件和单机的时候一样，主要修改以下几点
基本和主节点差不多，但要加上 slaveof 配置和主节点账号密码。

哨兵配置文件是 sentinel.conf ，因为有3个redis服务，所以启动3个哨兵服务，对应的配置文件分别为： sentinel_26381.conf 、 sentinel_26382.conf 、 sentinel_26383.conf
Redis服务和哨兵服务都启动了，可以测试哨兵的自动选举了，将6381沙雕，等几秒，再查看6382,6382的主从信息
注意：这个时候如果去看redis的配置文件，会发现配置文件中已经自动改好了主节点为6383了；而且哨兵的配置文件中，也改了主节点为6383了。这些都是哨兵帮我们做的
因集群中已有了新主节点，所以6381再启动只能作为从节点。此时6381启动，需要在配置文件中加入主节点信息：

Redis中的哨兵模式

哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。

这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：

配置哨兵配置文件sentinel.conf，如下

当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图

测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：

看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：

哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：

再来看一下从机即端口号是6380的redis服务器对应的配置文件是怎样改写的，如下图：

最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：

哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：

测试哨兵模式结果，如下图：

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。

2、主从可以切换，故障可以转移，系统的可用性就会更好。

3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

1、集群容量一旦到达上限，在线扩容十分麻烦。

2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。

当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：

Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。

当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。

该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。

如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：

详解redis集群选举机制

Redis哨兵模式（故障转移测试）

哨兵模式是在主备模式的基础上，加上哨兵，实现redis集群的故障转移。哨兵负责监控集群状态，当redis主节点发生故障，哨兵通过选举，选出替代的master节点。一般需要单数的哨兵进行选举，大多数达成一致。

问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。

为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。

本文章针对这个问题做一下实验。

使用3+3模式，3redis+3sentinel。

三台虚拟机，每台虚拟机运行1个redis+1个sentinel

ip、角色规划

??? 192.168.237.101：master，sentinel

??? 192.168.237.100：slave，sentinel

??? 192.168.237.103：slave，sentinel

安装redis、redis sentinel

??? apt-get install redis-server

??? apt-get install redis-sentinel

redis-server配置修改(/etc/redis/redis.conf)

???

redis-server slave配置修改

启动redis-server

??? /etc/init.d/redis-server restart

查看redis-server主从集群情况

修改sentinel配置(/etc/redis/sentinel.conf)

??? sentinel monitor mymaster 192.168.237.101 6379 2

??? sentinel known-slave mymaster 192.168.237.100 6379

??? protected-mode no

启动sentinel

??? /etc/init.d/redis-sentinel start

查看redis-sentinel情况

???

预期：故障转移，哨兵选举出新的master

关掉redis-server（192.168.237.101）

查看sentinel日志（/var/log/redis/redis-sentinel.log）

可以看到，+odown master，哨兵检测master客观下线

然后进行投票：vote-for-leader

选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379

192.168.237.101的sentinel日志：

查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）

恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave

预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完成故障转移。

经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server

查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：

查看redis集群状态，确认master（192.168.237.100）

预期：无法切换

依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master

查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票

恢复一个redis-sentinel，现有两个redis-sentinel

查看sentinel日志，选出101为master

????? 有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。

+sdown：主观down机

+odown：客观down机

+new-epoch：集群递增版本号

+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader

+try-failover：开始对某ip进行故障转移

voted for：另一个哨兵进行投票

+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。?

+selected-slave slave：选出leader

?+failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。

+failover-state-wait-promotion slave：等待其它的sentinel确认slave

+promoted-slave slave：其它的sentinel全部确认成功

+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)

+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master

+switch-master：故障转移完毕后，各个sentinel开始监控新的master