面试题：极端场景下Redis rehash的数据一致性挑战与应对

Question

假设在Redis进行rehash的过程中，突然遭遇大量的写操作以及网络分区故障，这会对数据一致性产生哪些严重影响，Redis理论上应如何应对这些极端场景以最大程度保证数据一致性

Answer 1

对数据一致性的严重影响

1. 数据丢失：在网络分区故障下，主从节点间无法同步数据。写操作若发生在主节点，而网络分区导致从节点无法及时同步，一旦主节点发生故障且未完成持久化，这部分新写入数据可能丢失。
2. 数据不一致：在rehash过程中，大量写操作会导致哈希表持续变动。若此时网络分区，主从节点哈希表状态可能不同步，当网络恢复后，主从节点间数据可能存在不一致。比如主节点新写入数据被分配到新哈希桶，但从节点因网络问题仍使用旧哈希表结构，未将新数据放入正确位置。

Redis应对极端场景保证数据一致性的方法

1. 持久化策略：
   • AOF（Append - Only File）：采用AOF持久化时，每次写操作都会追加到AOF文件。在网络分区故障恢复后，可通过重放AOF文件恢复数据。配置合理的AOF刷盘策略（如always、everysec、no），always策略能保证每次写操作都同步到磁盘，但性能相对较低；everysec策略每秒刷盘一次，兼顾性能与数据安全；no策略由操作系统决定刷盘时机，性能高但可能丢失较多数据。
   • RDB（Redis Database）：定期生成RDB快照文件，在发生故障重启时可快速恢复数据。可配置save参数控制快照生成频率，如save 900 1表示900秒内至少有1次写操作就生成快照。但RDB快照生成是全量的，两次快照间的数据在故障时可能丢失。可结合AOF和RDB，利用RDB快速恢复数据，利用AOF保证数据完整性。
2. 主从复制与故障恢复：
   • 主从同步：网络分区故障恢复后，主节点会将积压缓冲区中的写命令同步给从节点，使从节点数据与主节点保持一致。在rehash过程中，主节点会将哈希表变动信息也通过复制同步给从节点。
   • 哨兵（Sentinel）：监控主从节点状态，当主节点发生故障时，自动选举新的主节点，并让其他从节点重新同步新主节点数据。哨兵通过多数投票机制保证选举的可靠性，从而减少数据不一致时间。
3. 哈希表优化：
   • 渐进式rehash：Redis采用渐进式rehash，在rehash过程中，不是一次性将所有数据从旧哈希表迁移到新哈希表，而是分多次迁移。在每次处理客户端请求时，顺带迁移部分数据。这样在大量写操作时，能减少哈希表变动对数据一致性的影响，因为每次变动范围较小，主从节点同步相对容易。
   • 双哈希表结构：在rehash过程中，使用新旧两个哈希表，客户端的读写操作同时在新旧哈希表上进行。写操作时，新数据同时写入新旧哈希表；读操作时，先从新哈希表查找，若未找到再从旧哈希表查找。待旧哈希表数据全部迁移完毕，释放旧哈希表，完成rehash。这种方式保证了在rehash过程中数据读写的一致性。