面试题：在高并发场景下如何选择Redis的持久化策略

Question

假设你正在开发一个高并发的电商秒杀系统，每秒有数千个请求，系统要求尽可能保证数据不丢失，同时要兼顾性能，你会如何选择Redis的持久化策略，为什么？并说明在这种场景下，所选策略可能面临的问题及解决方案。

Answer 1

持久化策略选择

选择 AOF（Append - Only - File）持久化策略为主，结合 RDB（Redis Database）策略辅助。

选择 AOF 的原因

1. 数据完整性：AOF 以日志形式记录每次写操作，能最大程度保证数据不丢失。在高并发电商秒杀场景下，数据的准确性至关重要，AOF 可以通过配置 appendfsync 选项为 everysec，每秒将缓冲区数据写入磁盘，即使系统崩溃，最多丢失一秒的数据。
2. 性能兼顾：虽然 AOF 记录写操作会带来一定性能开销，但相比其他完全同步的持久化方式，appendfsync everysec 这种异步操作方式对性能影响相对较小，能满足每秒数千请求的高并发场景。

结合 RDB 的原因

1. 恢复速度：RDB 是对整个 Redis 数据的快照，在数据恢复时，由于是直接加载二进制数据，恢复速度比 AOF 快很多。在系统重启时，先加载 RDB 文件恢复大部分数据，再结合 AOF 日志重放增量数据，能加快整体恢复速度。
2. 数据备份：RDB 文件是一个紧凑的二进制文件，适合用于数据备份和灾难恢复。定期生成的 RDB 文件可用于数据的长期保存和异地容灾。

所选策略可能面临的问题及解决方案

AOF 面临的问题及解决方案

1. 文件体积膨胀：随着写操作不断进行，AOF 文件会持续增长。
   • 解决方案：使用 BGREWRITEAOF 命令，Redis 会在后台重新生成一个压缩后的 AOF 文件，该文件仅包含恢复数据所需的最小指令集。可以通过配置 auto - aof - rewrite - min - size 和 auto - aof - rewrite - percentage 来自动触发重写机制。
2. 重写期间性能影响：在 BGREWRITEAOF 执行期间，虽然是后台操作，但仍可能对主线程产生一定影响，因为需要复制内存数据。
   • 解决方案：可以选择在系统低峰期手动触发 BGREWRITEAOF，或者优化系统资源，确保在重写期间有足够的资源来支持主线程的正常运行。

RDB 面临的问题及解决方案

1. 数据丢失风险：RDB 是定期生成快照，两次快照之间的数据如果发生系统故障会丢失。
   • 解决方案：结合 AOF 持久化策略，利用 AOF 记录两次 RDB 快照之间的写操作，以减少数据丢失。
2. 生成快照时性能影响：在执行 SAVE 或 BGSAVE 生成 RDB 快照时，SAVE 会阻塞主线程，BGSAVE 虽然是后台操作，但也会消耗额外的 CPU 和内存资源。
   • 解决方案：尽量使用 BGSAVE，并且同样选择在系统低峰期触发快照生成。还可以优化服务器硬件配置，提高系统处理能力，以降低对正常业务的影响。