开发者学堂课程【Redis 入门实战演练： Redis 哨兵及实现（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/653/detail/10840
Redis 哨兵及实现（一）
内容介绍
一、 redis 集群
二、 如何实现 Master 和 Slave 的无缝切换？
三、 手动配置 master
四、 哨兵配置
一、 redis 集群：
上一个步骤的主从架构无法实现 master 和 slave 角色的自动切换，即当 master 出现 redis 服务异常、主机断电、磁盘损坏等问题导致maste 无法使用，而 redis 高可用无法实现自故障转移(将 slave 提升为 master，无法自动将 slave 提为 master，除了手动操作)，需要手动改环境配置才能切换到 Save redis 服务器，另外也无法横向扩展 Redis 服务的并行写入性能(无论有多少个 Save redis 服务器，同时启是要靠单台的 master 来决定，这就是它的任务结点。其他的任务结点就是起到了跨服务器备份的能力，对性能没有任何提升能力)，当单台 Redis 服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题，即：1.master 和 slave 角色的无缝切换，让业务无感知从而不影响业务使用（master 完成之后可以自动将 slave 提升为 master，尽量不让业务感知，这个业务是有时间延迟的就类似于 keepalive 一样。即使时间设定的很短，这种迁移会丢失一两个包或是延迟几秒，这个 master 和 slave 的切换也会存在这样的时间。这已经将故障降到最低，可以认为这一两秒是不影响slv的，所以第一个是 master 和 slave 的切换） 2.可以横向动态扩展 Redis 服务器，从而实现多台服务器并行写入以实现更高并发的目的。（这个并行目的就是会先写一个动态主库，这个主库会受到网络限制、内存大小限制等多种条件限制，但是如果是做成集群的话，它会横向拓展写入能力，一部分数据写入这个服务器，一部分写入到主服务器上去，那么写入能力相当于，有几个主就等于在一定程度上或是原来的基础只是横向扩大几倍）主要基于master和slave的自动切换来实现故障的自治愈，用横向扩展redis服务器提高集群并行写入的能力，这个并行写入能力主要是针对下面的实现方式：
Redis:集群实现方式；客户端分片 代理分片 Redis Cluster，这几个功能会在下次课程中讲到。
二、如何实现 Master 和 Slave 的无缝切换？
（1）Sentinel(哨兵)：【就类似于电影中防范坏人的守卫，一旦有坏人靠近，就会向领导发出警报。对 Redis 来说，这个哨兵就是用来监控的当前 redis 集群中的 master，如果当前 master down 完之后，就会一个通知一个选举，这个功能比站岗的人功能更多，还具有投票选举的功能。】
那么是怎样选举的？
Sentinel 进程是用于监控 redis 集群中 Master 主服务器工作的状态，在 Master 主服务器发生故障的时候。可以实现 Master 和 slave 服务器的切换，保证系统的【redis 服务器】高可用，其已经被集成在 redis2.6+的版本中【就是高于2.6版本的都会自带哨兵性质】，Redis 的哨兵模式到了2.8版本之后就稳定下来。一般在生产环境也建议使用 Redis 的2.8版本的以后版本【一般在公司可以安装3.0版本的】，哨兵(Sentinel)是一个分布式系统，可以在一个架构中运行多个哨兵(Sentinel)进程【哨兵也是要有多个的，这是因为哨兵是需要选举的。所谓的选举至少数量是不能小于1的，这是类似于共性选举的，是需要每一个哨兵的投票，这是一个典型的分布式的集群功能，多节点具备投票功能】，这些进程使用流言协议(gossip protocols)来接收关于 Master 主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移，以及选择哪个 Slave 作为新的Master【是哨兵选出来的谁是 master】。每个哨兵(Sentinel)进程会向其他哨兵(Sentinel)、Master、Slave 定时发送消息，以确认对方是否“活”着，如果发现对方在指定配置时间（可配置的）内未得到回应，则暂时认为对方已掉线，也就是所谓的“主观认为宕机【是它认为掉线的】”，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称：Subjective Down，简称 SDOWN。主观宕机就是每一个哨兵都可以认为哨兵 DOWN，而实际上 master 到底是不是在线和主观的关系不大。主观是自己认为是不是 DOWN，也有可能是自己的原因，像网线断了，到 master 的网络不同就会认为 master 断掉。有主观宕机，肯定就有客说宕机，当“哨兵群”中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过 SENTNEL is-master-down-by-addr 命令互相交流之后，【如果说多个哨兵都认为断掉并且通过】得出的 Master Server 下线判断，这种方式就是“客观宕机”，客现是不依赖于某种意识而已经实际存在的一切事物，英文名称是：Objectively Down，简称 ODOWN。哨兵就是通过一定的 vote 算法，从剩下的 Slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置【就是修改 redis config 文件】，并开启故障转（failover）。当哪一个哨兵检测到 Sentinel 机制可以解决 master 和 slave 角色的切换问题。当哨兵检测到 master down 之后会在剩下的 slave 中选择一个新的 master。
（2）具体示例：
现在有一个 Master 是172.31.7.101，它下面有两个是172.31.7.102和172.31.7.103，这两个都是101的 slave。目前是一主两从，是需要自己做好的，哨兵是不会进行主从同步，这就需要先进行主从同步。主从同步后，在安装哨兵，这个哨兵可以在单独的服务器装，也可以是在 redis 服务器上。公司一般是在一个服务器上装，一般不会拆开用多个服务器。与其将6个服务器来做还不如都用在集群上。
现在 Master 是172.31.7.101，哨兵1、2、3的配置文件都会监控 Master，监控172.31.7.101结点的 Master 是否正常，如果不正常哨兵1、2、3会进行协商，首先每个哨兵都认为 Master 挂了，这个是主观宕机，宕机之后会它们会进行协商，得出 Master 都宕了最终的到客观宕机，也就是Master真的宕机，然后哨兵会在剩下的两个节点也就是172.31.102和172.31.7.103，在这两个服务器节点中选出一个新的 Master，那这个 Master 可能是172.31.7.102或者是172.31.7.103。但是无论是哪个选成 Master，如果172.31.7.102选成 Master，那么哨兵会自动把172.31.7.103的配置的 Master 指向172.31.7.102，并且还会让172.31.7.103向172.31.7.102进行一次完整的数据同步，也就是以172.31.7.102的数据为准，把之前172.31.7.101的数据全部清空掉。这会个时候整个 Redis 中172.31.7.101就宕机了，这个 master 就变成172.31.7.102，slave 就成为172.31.7.103。如果172.31.7.103为 master, 那么哨兵会让172.31.7.101向172.31.7.103进行一次完整的数据同步，也就是以172.31.7.103的数据为准，把之前172.31.7.101的数据全部清空掉，还会修改172.31.7.102到 redis config 的配置文件。
如何操作？
环境应该是正常的，不算上172.31.7.104。172.31.7.102和172.31.7.103应该是已经连接到节点上的。
先输入语句 AUTH linux39和info，查看当前状态，运行结果可以看到172.31.7.101的状态是 master，slaves 0 是172.31.7.102。
将172.31.7.103连接到172.31.7.101上，
输入语句
1.ss -tnl
2.vim /apps/redis/etc/redis.conf
做哨峰的前提是配置一个 redis 主从配置的环境，这是第一步，语句运行后，可以看到有 slave 的101。
把程序重启，输入语句systemctl restart redis，结果如下，可以看到172.31.7.103也已经连上，103就是正常的。之后就可以配置哨兵，这个哨兵是编译中有的，只要有这样的 Sentinel 命令就可以，所以 Sentinel 哨兵机制可以解决 master 和 slave 角色的切换问题
