Redis-持久化、主从、哨兵及集群架构
Redis持久化
RDB快照
save 60 1000
bgsave的写时复制(COW)机制
|
命令
|
save
|
bgsave
|
|
IO类型
|
同步
|
异步
|
|
是否阻塞redis其他命令
|
是
|
否（在生成子进程执行调用fork函数时会有短暂阻塞）
|
|
复杂度
|
O(n)
|
O(n)
|
|
优点
|
不会消耗额外内存
|
不阻塞客户端命令
|
|
缺点
|
阻塞客户端命令
|
需要fork子进程，消耗内存
|
AOF（append-only file）
#appendonly yes
appendfsync always:每次有新命令追加到AOF文件时就执行一次fsync，非常慢，也非常安全 appendfsync everysec:每秒fsync一次，足够快，并且在故障时只会丢失1秒的数据
appendfsync no:从不fsync，将数据交给操作系统来处理。更快，也更不安全的选择。
推荐的措施为everysec，可兼顾速度和安全性。
AOF重写
127.0.0.1:6379> incr readcount (integer) 1 127.0.0.1:6379> incr readcount (integer) 2 127.0.0.1:6379> incr readcount (integer) 3 127.0.0.1:6379> incr readcount (integer) 4 127.0.0.1:6379> incr readcount (integer) 5
重写AOF文件里变成：
*3 $3 SET $2 readcount $1 5
如下两个配置可以控制AOF自动重写频率：
#aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就快，重写意义不大 #auto-aof-rewrite-min-size 64mb #aof文件自动上一次重写后文件大小增长了100%则再次触发重写 #aof-aof-rewrite-percentage 100
当然，AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF。
注意：AOF重写redis会fork出一个子进程去做（与bgsave命令类似），不会对redis正常命令处理有太多的影响。
RDB与AOF的选择
| 命令 | RDB | AOF |
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 容易丢数据 | 根据策略决定 |
生产环境都可以启用，redis启动时如果既有rdb文件又有aof文件则会优先选择aof文件恢复数据，因为aof一般来说数据更安全一点。
Redis4.0混合持久化
重启Redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在Redis示例很大的情况下，启动需要花费很长的时间。Redis4.0为了解决这个问题，带来了一个新的持久化选项——混合持久化。
通过如下配置可以开启混合持久化（必须先开启AOF）：
# aof-use-rdb-preamble yes
如果开启了混合持久化，AOF在重写时，不再是单纯的将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
于是Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放，因此重启效率大幅得到提升。
Redis数据备份策略
- 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份。
- 每天都保存一份当日的数据备份到一个目录中去，可以保留近1个月的备份。
- 每天晚上将当前机器声的备份复制到其他机器上，以防机器损坏。
Redis主从架构
Redis主从工作原理
如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，他都会发送一个PSYNC命令给master请求复制数据。master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的salve。
如果有很多从节点，为了缓解主从复制风暴（多个从节点同时复制主节点导致主节点压力过大），可以做如下架构，让部分从节点与从节点（与主节点同步）同步数据。
主从复制流程图：
全量复制
部分复制
管道（Pipeline）
客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipiline方式打包命令发送，redis必须在处理完所有命令先前缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。
pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中命令失败，后面命令不会有影响，继续执行。
Lua脚本
Redis在2.6版本推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下：
- 减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。类似于管道。
- 原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令（类似mset）是原子的。
- 替代redis的事务功能：redis自带的事务功能很鸡肋，报错不支持回滚，而redis的lua脚本几乎实现了常规的事务功能，支持报错回滚操作，官方推荐如果要使用redis的事务功能可以用redis lua替代。
//初始化商品10016的库存
jedis.set("product_stock_10016","15");
String script = " local count = redis.call('get', KEYS[1]) " +
" local a = tonumber(count) " +
" local b = tonumber(ARGV[1]) " +
" if a >= b then " +
" redis.call('set', KEYS[1], a-b) " +
" return 1 " +
" end " +
" return 0 ";
Object obj = jedis.eval(script, Arrays.asList("product_stock_10016"), Arrays.asList("10"));
System.out.println(obj);
注意：不要在Lua脚本中出现死循环和耗时的运算，否则redis会阻塞，将不接受其他的命令，所以使用时注意不能出现死循环，耗时的运算。redis是单进程、单线程执行脚本。管道不会阻塞redis。
Redis哨兵高可用架构
sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会在第一时间感知到，并且将新的redis主节点通知给client端（这里redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息）。
哨兵实例基本配置
#sentinel monitor <master-name> <ip> <redis-port> <quorum> #quorum是一个数字，指明当有多少个sentinel认为一个master失效时（sentinel总数/2 + 1），master才算真正失效 sentinel monitor mymaster 127.0.0.1 6379 2 #启动sentinel哨兵实例 src/redis-sentinel sentinel-26379.conf #查看sentinel的info信息 src/redis-cli -p 26379 127.0.0.1:26379>info 可以看到Sentinel的info里已经识别出了redis的主从
浙公网安备 33010602011771号