Redis如何保证服务宕机时的数据可靠性？

写在前面的话：

今天笔者遇到一个问题，Redis 如何在服务宕机时保证数据的可靠性——数据的持久化和一致性，发现对部分知识点的理解还不够深入，故这里记录一下学习笔记

当Redis作为缓存使用时，一旦宕机，会导致内存中的数据全部丢失，请求直接打到后端，可能引起一系列连锁反应

为了降低数据丢失带来的影响，Redis 提供了AOF（Append Only File）日志和 RDB 快照（Redis Database Backup file）两种方式进行数据持久化

在数据库中比较常提到的是WAL（Write-Ahead Logging，预写日志系统），比如 MySQL 的写操作并不是立刻更新到磁盘上，而是先记录在日志上，然后在合适的时间再更新到磁盘上。这样的好处是错开高峰期

而AOF 日志正好相反，它是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志

写后日志这种方式，就是先让系统执行命令，只有命令能执行成功才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况；而且命令执行后才记录日志，不会阻塞当前的写操作，更适合 Redis 这种高性能的场景

AOF 方法在恢复数据时可能存在操作日志过大、恢复速度慢等问题，而 RDB 则可以解决部分问题：

Redis 将某一时刻的内存快照保存在磁盘上，即使宕机，快照文件也不会丢失，快照文件就称为 RDB 文件。和 AOF 相比，RDB 记录的是某一时刻的数据而不是操作，所以在做数据恢复时可以快速把数据读入内存进行恢复

Redis 4.0 中提出了一种混合使用 AOF 和 RDB 的方法：内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作

这样做的好处是不需要频繁执行快照操作避免对性能的影响，AOF 日志也只用记录两次快照间的操作，不会出现文件过大的情况，避免重写开销（只需要记录上一次 RDB 至今的所有操作），在实践中可以获得很大的性能提升

AOF 和 RDB 一定程度上保证在服务宕机时数据不丢失，但如果是单机器服务，在宕机时仍会导致一段时间的服务不可用。而 Redis 的解决方案是增加副本数量，多个实例保存同一份数据，保证在服务宕机时能及时切换到备份实例上

但增加冗余量的同时，也增加了数据同步的消耗，Redis 提供了主从库模式以保证数据副本的一致，主从库之间为了兼顾效率和一致性采用了读写分离的方式

如下图所示，读操作可以同时访问主/从副本，而写操作只会发送给主副本，然后同步到所有的从副本上，读写分离可以保证数据在主从副本上的一致性

按照如上的架构方式，主从副本之间的同步可以分为首次同步——发送RDB快照、非首次同步——基于长链接的命令传播两种方式

具体来说，主从集群的数据同步，是数据可靠的基础保证；而在主库发生故障时，自动的主从切换是服务不间断的关键支撑。Redis 的哨兵机制自动完成了以下三大功能，从而实现了主从库的自动切换，可以降低 Redis 集群的运维开销：

为了降低误判率，哨兵机制通常采用多实例的方式进行部署，多个哨兵实例通过“少数服从多数”的原则，来判断主库是否下线

我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表

0 人点赞