redis小小总结

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；

 

参考地址：https://www.cnblogs.com/kismetv/p/9609938.html

https://www.redis.net.cn/order/3669.html