redis-5，redis哨兵

Posted 2023-04-18 niko5960

redis哨兵

哨兵巡查监控后台master主机是否故障，如果故障了，根据投票数自动将某一个库转换为新主库，继续对外提供服务

主要作用

主从监控： 监控主从redis库是否运行正常
消息通知： 哨兵可以将故障转移的结果发送给客户端
故障转移： 如果master异常，可以进行主从切换
配置中心： 客户端通过连接哨兵来获得当前reids的主节点地址

redis架构说明

三哨兵，一主二从
哨兵只负责监控和维护集群，不存入数据

哨兵的配置文件和数据库是不一样的

配置文件参数说明

sentinel monitor <master-name> <ip> <redis-port> <quorum>
设置要监控的master服务器
quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数

哨兵运行的时候会在配置文件写入数据
配置文件最好一个实例一个文件

宕机的节点重连之后会成为slave节点

两个小问题
主节点断开之后从节点可能会出现
sever closed the connection

broken pipe
broken pipe通常是对端的管道断开，无法再对这个管道进行读写操作
该异常产生的时候对服务端没有多大影响

哨兵运行原理和选举原理

三哨兵监控一主二从

主观下线sdown：

单个sentinel检测到关于master的状态，从sentinel角度来看，如果发送了ping心跳后，在一定时间内没有收到回复，就达到了sdown条件
sentine配置文件中的down-after-milliseconds设置了判断主观下线的时长
默认30s

客观下线odown：

多个哨兵达成一致的意见就认为下线了

选举出领导者哨兵leader：

三个哨兵中选一个来执行slave到master
日志中可以看到选举过程

raft算法选举出来的领导者

自动故障切换并选出新master

选举算法：
priority权限：
谁高谁变成新master
redis.config文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
replication offset偏移量：
谁的偏移量大谁变成新master
run id：
最小run id的从节点 字典顺序：ascii码

redis哨兵模式

至此，我们了解并动手实践了redis的安装，redis单点，redis主从，redis 哨兵 sentinel，redis 集群cluster。
我们来梳理一下redis主从，redis哨兵，redis机器的区别和关系。

redis主从：是备份关系， 我们操作主库，数据也会同步到从库。 如果主库机器坏了，从库可以上。就好比你 D盘的片丢了，但是你移动硬盘里边备份有。
redis哨兵：哨兵保证的是HA，保证特殊情况故障自动切换，哨兵盯着你的“redis主从集群”，如果主库死了，它会告诉你新的老大是谁。
redis集群：集群保证的是高并发，因为多了一些兄弟帮忙一起扛。同时集群会导致数据的分散，整个redis集群会分成一堆数据槽，即不同的key会放到不不同的槽中。

主从保证了数据备份，哨兵保证了HA 即故障时切换，集群保证了高并发性。

一切动手做了才会熟悉。。

谈到Redis服务器的高可用，如何保证备份的机器是原始服务器的完整备份呢？这时候就需要哨兵和复制。

1. 哨兵(Sentinel)：可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能。
2. 复制(Replication)：则是负责让一个Redis服务器可以配备多个备份的服务器。

Redis正是利用这两个功能来保证Redis的高可用。

哨兵（sentinal）

哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

1.Redis哨兵主要功能

（1）集群监控：负责监控Redis master和slave进程是否正常工作

（2）消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

（3）故障转移：如果master node挂掉了，会自动转移到slave node上

（4）配置中心：如果故障转移发生了，通知client客户端新的master地址

2.Redis哨兵的高可用

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

1. 哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况。
2. 同时哨兵节点之间也互相通信，交换对主从节点的监控状况。
3. 每隔1秒每个哨兵会向整个集群：Master主服务器+Slave从服务器+其他Sentinel（哨兵）进程，发送一次ping命令做一次心跳检测。

这个就是哨兵用来判断节点是否正常的重要依据，涉及两个新的概念：主观下线和客观下线。

1. 主观下线：一个哨兵节点判定主节点down掉是主观下线。

2.客观下线：只有半数哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。

3.原理：基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

Redis 复制(Replication)

Redis为了解决单点数据库问题，会把数据复制多个副本部署到其他节点上，通过复制，实现Redis的高可用性，实现对数据的冗余备份，保证数据和服务的高度可靠性。

1.数据复制原理（执行步骤）

①从数据库向主数据库发送sync(数据同步)命令。

②主数据库接收同步命令后，会保存快照，创建一个RDB文件。

③当主数据库执行完保持快照后，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。

④主数据库将缓冲区的所有写命令发给从服务器执行。

⑤以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。

注意：在Redis2.8之后，主从断开重连后会根据断开之前最新的命令偏移量进行增量复制。

Redis 主从复制、哨兵和集群这三个有什么区别

 

1.主从模式：读写分离，备份，一个Master可以有多个Slaves。

2.哨兵sentinel：监控，自动转移，哨兵发现主服务器挂了后，就会从slave中重新选举一个主服务器。

3.集群：为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

哨兵作用于高可用，集群提高并发量，具体Redis集群方案详情，可以参考：高并发架构系列：详解Redis的存储类型、集群架构、以及应用场景

 

 

 

二、持久化


        那么这么多，这么重要的数据都存储在内存中，如果突然断电，岂不是很糟糕，于是就有了数据的持久化机制，这个其实就是把内存中的数据存储到硬盘中，方便数据的持续存在，也可以减少断电造成的损失。

        那么我们怎么持久化数据呢？多长时间进行一次持久化呢？

redis 支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是 Append-only file（缩写 aof）的方式。下面分别介绍：

     一)、Snapshotting

         快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置：

    save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存
    save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存
    save 60 10000


下面介绍详细的快照保存过程：

        1.redis 调用 fork,现在有了子进程和父进程。

        2. 父进程继续处理 client 请求，子进程负责将内存内容写入到临时文件。由于 os 的实时复制机制（ copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时 os 会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程地址空间内的数据是 fork时刻整个数据库的一个快照。

        3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程中保存快照的，由于 redis 是用一个主线程来处理所有 client 的请求，这种方式会阻塞所有client 请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘 io 操作，可能会严重影响性能。


       二)、AOF方式

        由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化方式。下面介绍 Append-only file:aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式时,redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于 os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样 aof 方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。有三种方式如下（默认是：每秒 fsync 一次）


    appendonly yes //启用 aof 持久化方式
    # appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
    appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
    # appendfsync no //完全依赖 os，性能最好,持久化没保证

        aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的。因为要恢复数据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。 redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。