redis 总结:
redis 持久化分为RDB持久化和AOF持久化
RDB: 将数据保存到硬盘 AOF : 将每次执行的写命令保存到硬盘
RDB 持久化的触发分为手动触发和自动触发两种
手动触发:
save 命令会阻塞redis 服务器进程,知道RDB文件创建完毕为止,在redis 服务器阻塞期间,服务器不能处理任何请求
bgsave :会创建一个子进程,由子进程来创建RDB文件,父进程(redis)继续处理请求
自动触发:
save m n 在redis.conf 的配置文件中
save 900 1
save 300 10
save 60 10000
当时间到900s 时,如果redis数据发生了至少1次变化,则执行bgsave ,三个条件满足任意一个时,都会引起bgsave 的调用
其他自动触发机制:
1.在主从复制场景下,如果从节点执行全量复制操作,主机点会执行bgsave命令,并将rdb 文件发送给从节点。
2.执行shutdown 命令时,自动执行 rdb 持久化分为RDB持久化
RDB 常用配置总结:
save m n:bgsave自动触发的条件;如果没有save m n配置,相当于自动的RDB持久化关闭,不过此时仍可以通过其他方式触发
stop-writes-on-bgsave-error yes:当bgsave出现错误时,Redis是否停止执行写命令;设置为yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;设置为no,则Redis无视bgsave的错误继续执行写命令,当对Redis服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为no
rdbcompression yes:是否开启RDB文件压缩
rdbchecksum yes:是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现
dbfilename dump.rdb:RDB文件名
dir ./:RDB文件和AOF文件所在目录
AOF持久化:
AOF持久化 将redis执行的每次写命令 记录到单独的日志文件中。 与rdb相比,AOF的实时性更好 。
开启AOF:
redis默认开启RDB ,关闭AOF ,开启AOF:在配置文件中 :appendonly yes
RDB与AOF优缺点:
RDB优点: RDb文件紧凑,体积小,网络传输快,适合全量复制,回复速度比AOF快。 缺点: 数据快照的持久化方式,做不到实时数据持久化,会丢失数据。
AOF 优点: 秒级持久化 缺点: 文件大,恢复速度慢,对性能影响大。 AOF向硬盘中写文件的频率更高,会对redis 主进程性能影响较大
info命令与持久化:
info Persistence
rdb_last_bgsave_status:上次bgsave 执行结果,可以用于发现bgsave错误
rdb_last_bgsave_time_sec:上次bgsave执行时间(单位是s),可以用于发现bgsave是否耗时过长
aof_enabled:AOF是否开启
aof_last_rewrite_time_sec: 上次文件重写执行时间(单位是s),可以用于发现文件重写是否耗时过长
aof_last_bgrewrite_status: 上次bgrewrite执行结果,可以用于发现bgrewrite错误
aof_buffer_length和aof_rewrite_buffer_length:aof缓存区大小和aof重写缓冲区大小
aof_delayed_fsync:AOF追加阻塞情况的统计
info stats:
其中与持久化关系较大的是:latest_fork_usec,代表上次fork耗时
主从复制:
从节点开启主从复制:
1.在从服务器的配置文件中加入:slaveof <masterip> <masterport>
2.Redis服务器启动后,直接通过客户端执行命令:slaveof <masterip> <masterport>,则该Redis实例成为从节点。
断开复制:
slaveof no one
哨兵:
redis sentinel
最简单配置部署主从节点 和哨兵节点:
主节点(port=6379) 从节点(port=6380 6381)
#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379
启动节点
./redis-cli redis.conf
部署哨兵节点
哨兵节点本质上是特殊得到redis节点,3个哨兵节点的配置几乎是完全一样的,主要区别的端口号的不同(26379/26380/26381)
哨兵的最简单配置 3台哨兵节点的配置几乎完全一样,主要区别在于端口号的不同(26379/26380/26381) sentinel.conf配置从解压完的的目录拷贝到编译后的bin目录
#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2
(sentinel monitor mymaster 192.168.92.128 6379 2)的含义是该哨兵节点监控 192.168.92.128 这个主节点,该节点的名称是 mymaster 。2的含义是,至少2个哨兵节点同意,才能判定主节点故障并进行故障转移
哨兵的启动方式:
./redis-sentinel sentinel-26379.conf
此时已经发现哨兵节点的配置文件会发生变化,多了一些配置文件:
sentinel known-slave hunan2 127.0.0.1 6381
sentinel known-slave hunan2 127.0.0.1 6379
sentinel known-sentinel hunan2 127.0.0.1 26379 4e8fb90950a18293b664abeb4aaa2df23e321f7b
sentinel known-sentinel hunan2 127.0.0.1 26380 b6032075d6860c6b48070f0c5786af5775ffb254
sentinel current-epoch 1
known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵;带有epoch的参数与配置纪元有关(配置纪元是一个从0开始的计数器,每进行一次领导者哨兵选举,都会+1;