1. redis持久化

除了通过RDB和AOF的方式把数据持久化到本地磁盘，还可以定期将RDB/AOF文件备份到安全的云服务器（冷备）

1.1 RDB快照（snapshot）

默认，redis快照保存在dump.rdb的二进制文件中

当然，也可以对redis进行设置，在“ N秒内数据集只少有M个改动 ”，会进行一次保存

如：60秒内有10000个键改动，保存一次

save 60 10000

注释掉save即可关闭save命令

手动快照：手动执行命令save 或 bgsave生成dump.rdb文件，生成新的rdb并覆盖原文件

save是同步命令，bgsave是异步，bgsave会从redis主线程fork一个子线程专门生成rdb快照

save和bgsave对比：

1.2 AOF（append-only file）

其实，RDB方式不是很安全，RDB在一定时间内一定操作数才进行数据保存，这段时间宕机，数据就会丢失。

AOF：将修改的每一条指令进文件appendonly.aof中

打开AOF： 打开注释 # appendonlly yes

写入到AOF文件中，并不是马上就写入，而是会先写到linux的os cache里面，然后一定时间在从os cache fsync到disk file（AOF）

每执行一个改变指令，都会追加到appendonly文件后面

redis重启的时候，会重新执行AOF命令来重建数据

配置redis多久刷新数据到磁盘

• appendfsync always：每次有新命令追加到AOF文件就执行一次fsync，慢但安全
• appendfsync everysec：每秒fsync一次
• appendfsync no：从不fsync，fsync交给系统处理，但不安全。
• 推荐（也是默认）每秒fsync一次，这种可以兼顾速度和安全

一旦fsync超过2S，redis就会被拖慢

1.2.1 AOF重写

因为aof可能存在很多冗余的指令，aof会定期根据内存重写aof文件（把旧的文件删除）

可配置aof自动重写频率

aof文件要达到64MB才会进行自动重写，文件太小恢复速度快，没有必要

auto-aof-rewrite-min-size 64mb

aof文件距离上次重写后文件增长了100%触发重写

aotu-aof-rewirit-percentage 100

手动重写：通过bgrewriteaof重写

aof重写redis会fork一个子线程去做，不会影响正常命令执行

RDB和AOF对比

如果同时开启了RDB和AOF，会优先执行AOF，数据更安全

Redis4.0 增加混合持久化

由于RDB容易丢失数据，但是AOF性能低，当redis实例多，启动花费时间多，就出现了混合持久化

aof-use-rdb-preamble yes

AOF重写时，将重写此刻之前的内存就 RDB快照，RDB快照和重写后的AOF命令一起放入AOF文件中

1.3 AOF和RDB选择

• 不要仅使用RDB，可能会丢失很多数据
• 也不要仅使用AOF，AOF恢复数据没有RDB快，AOF生成命令或rewrite时可能出现指令bug，导致恢复数据不全
• 综合使用两种，用AOF保证数据不丢失，作为恢复第一选择，RDB用来做冷备，在AOF文件不可用时，可用RDB快速恢复

2. redis主从

2.1 原理

master配置了slave，无论slave是否是第一次连接master，slave会发送一个SYNC命令，请求数据。

master收到命令，进行持久化通过bgsave生成rdb快照文件，这段时间，不会影响接收客户端的数据，会把客户端的请求数据缓存到内存中，当持久化结束，master会把rdb文件数据集发给slave，slave把数据加载到内存中。然后，master把之前缓存到内存中的命令发送给slave

slave支持自动重连，master有多个slave，只会进行一次持久化

一份大的rdb文件，发送给多个slave，会导致网络带宽被严重占用，master挂载slave，可以采用树状结构

数据部分复制

从版本2.8，slave和master支持重连后部分数据复制

master会在内存中创建一个复制数据用的缓存队列，master维护它所有的slave复制的数据的下标offset和进程id，下次重连会通过master的进程id和下标offset进行继续复制。如果master的id变了或节点下标offset太旧，会重新进行全量复制

2.2 主从搭建

搭建一个最基础的，基于同一个redis，不同的配置文件

1. 复制一个redis.conf文件，命名为redis_6378.conf2. 修改对应配置 port 6378 pidfile /var/run/redis_6378.pid logfile "6378.log" dir /usr/local/redis-5.0.11/data/63783. 配置主从复制 # 从本机6379redis复制数据 replicaof 127.0.0.1 6379 replica-read-only yes4. 启动从节点 src/redis-server redis_6378.conf5. 连接主节点 src/redis-cli -p 63796. 写入数据 set destin 33337. 连接从节点 src/redis-cli -p 63788. 查看数据是否同步 get destin

3. redis哨兵高可用

sentinel哨兵是特殊的redis服务，不提供读写服务，是用来监控redis节点

client第一次从哨兵找出redis的master节点，之后就直接访问master节点，不会每次通过sentinel代理访问master节点，当master节点发生变更，sentinel会第一次时间感知，并将新的master节点告知client，redis的client都有订阅功能，订阅sentinel发布的变更信息

redis哨兵之间互相发现，是通过redis的pub/sub实现，哨兵节点每隔2S往channel里面发送消息，内容是host、ip、runid

哨兵监控高可用：

• odown：slave节点认为另外节点挂了
• sdown：哨兵主观认为节点挂了

如果master挂了，而Majority哨兵都允许了主备切换，哨兵选举考虑slave信息：

• master断开的时长
• slave优先级
• 复制offset，与master数据的新旧度，新的越有机会
• runid

如果一个slave和master断开时长超过down-after-milliseconds的10倍，加上master宕机时长，该slave不适合选举为master

最终选举：

• slave优先级排序，slave priority越低，优先级越高，默认100
• 相同情况，看replica offset，复制数据越多，优先级越高
• 上面相同，选择run id较小的

3.1 哨兵搭建

1. 复制一份sentinel.conf文件为sentinel-26379.conf
	cp sentinel.conf sentinel-26379.conf
2. 修改配置
	port 26379
	daemonize yes
	pidfile "/var/run/sentinel-26379.conf"
	logfile "26379.log"
	dir "/usr/local/redis-5.0.11/data"
	# sentinel monitor <master-name> <ip> <redis-port> <quorum>
	# quorum数字，表示当前有多少个sentinel认为master失效（sentinel总数/2+1）才算失效
	# sentinel moitor master 127.0.0.1 6379 2
3. 启动哨兵
	src/redis-sentinel sentinel-26379.conf
4. 查看sentinel信息
	src/redis-cli -p 26379
	info
5. 可以配置多个sentinel哨兵，改对应配置文件的数值就行

搭建注意事项：

• redis服务和redis哨兵不要在一台物理机上
• 配置文件中bin 放开，写物理机IP，不要写127.0.0.1
• 名称可能 为master或者mymaster
• daemonize设置为yes
• protected-mode no（关闭保护模式）

RedisTemplate常用方法：