面试题：Redis复制过程中的数据一致性与高可用性的权衡

Question

在Redis实现高可用性的复制设计里，数据一致性和高可用性有时需要权衡。请详细阐述在不同的业务场景下，如何通过调整Redis复制配置参数来平衡数据一致性和高可用性，比如在电商库存扣减与社交点赞场景下的不同考量。

Answer 1

电商库存扣减场景

1. 数据一致性要求高：电商库存扣减场景对数据一致性要求极为严格，因为库存数量直接关系到商品是否超卖，影响消费者体验和商家利益。
2. 复制配置参数调整：
   • replica - read - only：设置为yes，确保从节点只用于读操作，主节点负责写操作，这样可以避免从节点写数据导致数据不一致。
   • min - replicas - to - write：可根据实际情况设置为大于等于1的值，比如设置为2。表示主节点在接收到至少2个从节点的确认回复后，才认为写操作成功。这样即使主节点故障，至少有2个从节点的数据是最新的，保证了一定程度的数据一致性。
   • min - replicas - max - lag：设置一个合理的时间值，如10秒。如果从节点的复制延迟超过10秒，主节点将拒绝写操作，防止数据在从节点长时间延迟同步，确保数据一致性。

社交点赞场景

1. 高可用性要求高：社交点赞场景更注重高可用性，用户点赞操作频繁，短暂的数据不一致（如点赞数在不同节点显示稍有延迟）对用户体验影响相对较小。
2. 复制配置参数调整：
   • replica - read - only：可以设置为no，允许从节点进行写操作。这样在主节点故障时，从节点能继续接收点赞写请求，保证系统可用性。不过这可能会引入数据一致性问题，比如多个从节点同时接收写操作，需要后期进行数据合并。
   • min - replicas - to - write：可以设置为0。主节点无需等待从节点确认就认为写操作成功，这能极大提高写操作的响应速度，提升系统可用性，但可能导致主从数据不一致。
   • min - replicas - max - lag：可以设置一个较大的值，如60秒。允许从节点有较长的复制延迟，以避免因从节点短暂延迟就拒绝主节点写操作，提高系统可用性。