redis哨兵集群架构

redis主从架构

 

redis主从架构搭建

从节点配置文件修改：

port 6380 pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件

logfile "6380.log"

dir /usr/local/redis-5.0.3/data/6380 # 指定数据存放目录

# 需要注释掉bind（bind代表允许客户端通过机器的哪些网卡ip去访问，这里不做限制，注释掉即可）

# bind 127.0.0.1

配置主从复制

replicaof 192.168.195.128 6379 # 从本机6379的redis实例复制数据，Redis 5.0之前使用slaveof

replica-read-only yes # 配置从节点只读

redis主从复制同步数据

redis部分数据同步（断点续传）

在redis2.8之后，redis支持slave从master节点复制部分数据，master节点会在内存中创建一个缓存队列，缓存最近一段时间的数据，而master和slave都会维护复制的数据下标（offset）和master进程id。当某个slave节点因某种原因导致网络与master断开，slave会发送pysnc命令并附带offset给master，master根据offset去缓存队列查offset对应的数据是否存在，存在则将offset之后的数据全部发送给slave，否则复制全量数据给slave。

redis主从复制风暴

如果多个从节点向主节点发送同步数据命令，这会导致主节复制风暴，即主节点压力过大。可以通过从节点挂从节点的架构解决。 

redis哨兵集群

redis哨兵集群高可用架构 

哨兵集群搭建

配置文件

port 26379 daemonize yes pidfile "/var/run/redis-sentinel-26379.pid"

logfile "26379.log"

dir "/usr/local/redis-5.0.3/data" #

sentinel monitor <master-redis-name> <master-redis-ip> <master-redis-port> <quorum> # quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般超过半数)，master才算真正失效

sentinel monitor mymaster 192.168.195.128 6379 2 # mymaster这个名字随便取，客户端访问时会用到

根据以上配置复制两个配置文件，并启动三个sentinel，如果sentinel出现类似下图内容表示sentinel识别了redis主从服务和其他sentinel节点

如果master节点发生变化，或者说kill master进程，sentinel会感知到redis发生变化，重新选举新的master并修改sentinel配置文件如图，并将新的master节点发送给客户端。

redis持久化

redis持久化主要有两种方式，分别是：RBD快照和AOF（append-only file）

RDB

redis触发生成RDB文件是通过配置文件中save n m保存策略，在n秒内发生了m次数据变化，进行全量数据生成rdb文件。rdb文件是二进制的，它恢复数据比较快，

save 60 100表示redis在60秒内发生100次数据修改就会自动保存redis内所有数据到rdb文件。

redis也支持客户端发送save或者bgsave命令生成rdb文件，bgsave是异步的，通过主线程fork出一个子进程去执行生成rdb文件。

配置文件中默认生成rdb文件是通过bgsave实现的。故他不能实时更新数据，redis挂掉后可能导致数据丢失

AOF

考虑到rdb不能实时更新磁盘数据，redis增加了一种耐持久的持久化策略就是AOF，它支持每隔一段时间就更新磁盘数据，追加到aof文件中，aof文件不是二进制的，故恢复数据效率不如rdb。

redis默认没有开启aof功能，可以配置开启aof，并有三个选项：redis默认每秒

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。 
appendfsync no：从不 fsync ，将数据交给操作系统来处理。

AOF重写

aof文件中可能存在很多没用的命令，比如业务需要执行某个key加一操作，aof就会记录很多该key加一命令。对于这种情况，redis会自动定期重写aof文件，并优化aof文件，只会记录set key 最后总数。也可以通过配置修改AOF自动重写频率。

redis4.0混合持久化

在看了AOF和RDB两种持久化方式后，不难看出给有千秋。因为RDB丢失数据量大，通常redis会使用AOF日志重放恢复数据，但是恢复效率低下，所以在redis4.0出现了混合持久化的方式。

通过配置文件中配置aof‐use‐rdb‐preamble yes项，表示开启混合持久化（必须先开启aof）。在aof重写时，会将当前时间之前的内存数据进行rdb快照处理写入新的aof文件，然后覆盖掉原有aof文件，新写入的命令追加到新的aof文件中。如此，redis在重启时，通过aof日志回放，实际先执行rdb二进制数据然后执行增量aof文件格式的数据，提升redis重启效率。