亿级流量、高并发与高性能场景下的电商详情页架构_3(Redis的持久化)

亿级流量、高并发与高性能场景下的电商详情页架构_3(Redis的持久化)

1：为什么需要持久化

持久化主要用于灾难恢复（高可用）

如果没有持久化，在redis挂掉之后，重启redis机器后，在redis中的内存上的数据就都不见了了，所有的就在redis里面找不到，引起缓存雪崩的情况，导致MySQL去承接了高并发。从而导致MySQL挂掉，这个时候MySQL挂掉了，Redis也无法从MySQL中获得数据。
所以Redis的持久化是很有必要的。

如果把Redis的持久化做好，备份和恢复方案做到企业级的程度，即使Redis发生了故障，也可以通过备份数据进行快速恢复，一旦恢复就对外提供服务

2：持久化的两种机制

1. RDB
   对redis中的数据执行周期性的持久化（每隔一段时间生成Redis内存上的一份完整数据快照）
   

2. AOF
   AOF机制是对每一条的写命令作为日志，通过append-only的方式将命令写入一个日志文件中.
   RDB和AOF都可以将Redis中的数据写入磁盘，随后只需将磁盘文件备份至云存储上就可以了，如果Redis挂了，服务器上的内存和磁盘上的数据都丢失，可以从云服务上下载对应的数据到指定目录下，然后重启Redis，Redis就会自动根据数据文件加载数据进内存，继续对外服务。
   如果RDB和AOF同时开启，则开机时会使用AOF来构建数据 ，因为AOF中的文件更加完整。

2：RDB和AOF的优缺点对比

RDB的优点

• RDB会生成多个数据文件，每个数据文件代表某个时刻中Redis的数据，这种多个数据文件的方式，非常适合去用作冷备，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据
  AOF生成一个数据文件，也可以做冷备份，但是需要写些脚本定时的copy一份。
  RDB作为冷备份比AOF简单很多，可以由Redis去控制固定时长生成快照文件
• RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可，每次写都是写入内存，只有在周期到的时候才写入磁盘
  AOF的话基本上每秒就要进行写入磁盘
• 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
  这是因为RDB机制存储的是内存的数据快照，直接加载进内存就可以了，AOF是写入指令日志，需要回放和执行指令集才能加载。

RDB的缺点

• 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据-—— RDB最大的缺点（如果RDB做第一优先恢复方案就会导致Redis的数据丢失得比较多）
• RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒——一般不要RDB间隔太长

AOF的优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作（OSCache写入磁盘），最多丢失1秒钟的数据
• AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
• AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

AOF的缺点

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的.
• 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
• 唯一比较大的缺点是数据恢复的时候比较慢，以及做冷备份的时候比较复杂

3：RDB和AOF要怎么选

1. 不要仅仅使用RDB，因为那样会导致你丢失很多数据
2. 也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

4：RDB

1：RDB的工作流程流程

1. redis根据配置自己尝试去生成rdb快照文件
2. fork一个子进程出来
3. 子进程尝试将数据dump到临时的rdb快照文件中
4. 新生成的rbd快照文件替换掉原来的那个快照文件
   dump.rdb，每次生成一个快照文件，并会替换掉原来的那个。

2：RDB的配置

在rdedis.conf里面配置SAVE

save 60 1000

每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照

也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成

3:RDB的测试

• 使用redis-cli关闭redis

1：在redis中加入几条数据

2：调用redis-cli SHUTDOWN

3：在登录时，调用get 查看插入的数据还在不在

发现是在的。这是由于 调用redis-cli SHUTDOWN是属于安全退出，在退出前，会给你创建一个快照文件。

• 使用kill -9强制杀掉redis进程模拟故障
  
  重新开启redis发现上次写入的数据丢失
  
  可以设置 save 5 1再测试一遍。

5：AOF

1：AOF持久化配置

1. AOF默认是关闭的，默认开启的是RDB持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓
   
2. 打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下，执行fsync有三种策略，
   一种是每次写入一条数据就执行一次fsync; appendfsync always
   一种是每隔一秒执行一次fsync; appendfsync everysec
   一种是不主动执行fsync appendfsync no

对应上面三种

always：性能非常差，吞吐量特别低。(这样可以确保每条数据都不丢失)
everysec：每秒将os cache的数据fsync到磁盘，这个是最常用的，生产环境通常也是这样配置，性能很高
no：仅仅redis负责将数据写入os cache然后就不管了，后面os会时不时的有自己的策略写入磁盘。（这样就不太可控）

2：AOF持久化数据恢复实验

（1）先仅仅打开RDB，写入一些数据，然后kill -9杀掉redis进程，接着重启redis，发现数据没了，因为RDB快照还没生成
（2）打开AOF的开关，启用AOF持久化
（3）写入一些数据，观察AOF文件中的日志内容

其实你在appendonly.aof文件中，可以看到刚写的日志，它们其实就是先写入os cache的，然后1秒后才fsync到磁盘中，只有fsync到磁盘中了，才是安全的，要不然光是在os cache中，机器只要重启，就什么都没了

（4）kill -9杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，就是从AOF文件中恢复回来的

redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来

3：AOF的rewrite

基础的rewrite上面已经讲得很详细了。
看一下redis.conf里面的两个关于rewrite的参数

auto-aof-rewrite-percentage 100
这个参数设置的是如果这次的AOF文件大小比上次的AOF文件超过百分之xx的话会触发rewrite。

auto-aof-rewrite-min-size 64mb
这个参数设置的是，要触发rewrite的最小AOF文件大小。

4：AOF的文件的破损修复

如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损

用redis-check-aof --fix命令来修复破损的AOF文件

5：AOF和RDB同时工作

（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting
（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整