Redis架构演进之单机版Redis和数据持久化

单机版Redis

假设现在有一个业务应用，需要引入Redis来提高应用的性能，此时可以选择部署一个单机版的Redis来使用

业务应用可以把Redis当作缓存来使用，从MySQL里查询数据，然后写入Redis中，之后业务应用再从Redis里读取数据，因为Redis的数据都是存储在内存里的，所以整体的速度很快。

随着业务的不断发展，Redis里存储的数据也越来越多，此时业务应用对Redis的依赖也越来越重，突然有一天Redis宕机了，这时候所有的业务流量，都会打到MySQL上，这时候MySQL的压力剧增，严重的话甚至会把MySQL打挂。

这时候需要怎么办呢？肯定是需要重启Redis，可以继续让它提供服务。但是因为Redis的数据都在内存里，即使重启也会丢失，Redis中依旧没有数据，业务流量还是会打到MySQL上，依旧解决不了问题。

那我们能不能把数据额外写一份到磁盘上呢？当Redis重启的时候，可以把磁盘中的数据快速恢复到内存中，这样就可以继续正常提供服务了。

数据持久化

把内存数据写到磁盘上的过程，就是数据持久化

那么持久化具体应该怎么做呢？很容易能够想到的一个方案是：Redis每一次执行写操作的时候，既写到内存上，同时也写一份到磁盘上。

这个方案的问题在于：客户端的每次写操作，既需要写内存，又需要写磁盘，而写磁盘的耗时比写内存要多很多，肯定会影响到Redis的性能

那么如何避免这个问题呢？

可以借助多线程的思想，Redis写内存由主线程来做，写内存完成后就给客户端返回结果，然后用另一个线程去写磁盘，这样可以避免主线程写磁盘对性能的影响。

除此之外，还可以结合Redis的适用场景来考虑怎么做持久化。Redis一般用于缓存，尽管Redis中没有保存全量数据，对于不在缓存里的数据，依旧可以通过查询数据库得到结果，对业务的结果没影响，所以可以用数据快照的方式做持久化

Redis的数据快照，就是记录某一时刻下Redis中的数据，然后只需要把这个数据快照写入磁盘就可以了。

优点在于：只在需要持久化的时候把数据一次性写入磁盘，其他时间都不需要操作磁盘。

所以第二个方案就是：定时给Redis做数据快照，把数据持久化到磁盘上。

刚刚说的这两个方案，对应Redis的RDB和AOF，他们的区别如下：

• RDB

  • 创建一个子进程，持久化某一时刻的数据快照到磁盘上

  • 采用二进制和数据压缩的方式写入磁盘，这样文件体积小，数据恢复速度快

• AOF

  • 每一次写操作都持久化到磁盘，主线程写入到内存，根据配置决定是主线程还是子线程进行数据持久化的操作

  • 记录每一次写命令，数据全，但是文件体积大，数据恢复速度慢

对于持久化方案的选择，可以遵循以下规则：

• 业务对于数据丢失不敏感，选择RDB

• 业务对数据完整性要求较高，采用AOF

假设选择的是AOF方案，又会遇到以下问题：

• AOF记录的是每一次写操作，随着时间增长，AOF的文件体积会越来越大

• 体积大的AOF文件，在数据恢复的时候变得很慢

那怎么样缩小文件体积，提升恢复速度呢？

可以从AOF的特点入手，AOF文件记录的是每一次的写操作，对于同一个key来说，可能会发生多次修改，我们只保留最后一次被修改的值就可以了。这就是AOF rewrite 。通过对AOF文件定期rewrite，避免这个文件体积持续膨胀，在恢复时就可以缩短恢复时间了

思考一下还有没有办法继续缩小AOF文件，回顾下RDB和AOF各自的特点，可以做混合持久化，当AOF rewrite的时候，Redis先以RDB格式在AOF文件里写入一个数据快照，再把在这期间产生的每一个写命令，追加到AOF文件里。因为RDB文件是二进制压缩产生的，AOF的文件体积就变得更小了。

Redis 4.0 以上才支持混合持久化