面试题：Redis在分布式系统中如何保证简单Redis对象的弱一致性

Question

在分布式系统场景下，简要阐述Redis保证简单Redis对象（如字符串类型）弱一致性的常用策略和机制。

Answer 1

异步复制策略

1. 主从复制：
   • 在Redis主从复制架构中，主节点负责处理写操作，然后将写命令异步发送给从节点。当客户端在主节点执行写操作（如设置一个字符串类型的键值对）后，主节点会立即向客户端返回成功响应，而不会等待从节点完成数据同步。这就可能导致在主从同步延迟期间，从节点的数据与主节点不一致，从而呈现出弱一致性。例如，主节点设置了SET key value，并向客户端回复成功，但此时从节点可能还未收到该写命令，客户端如果读取从节点，可能获取不到最新的value。
2. 读写分离：
   • 基于主从复制，应用程序通常会将读请求发送到从节点，写请求发送到主节点。由于主从复制的异步性，从节点可能落后于主节点。例如，当主节点更新了一个字符串类型的键值后，从节点可能需要一段时间才能同步到该更新，在这段时间内，从节点上读取的数据就是旧的，体现了弱一致性。

过期策略

1. 定期删除：
   • Redis会定期随机抽取一些设置了过期时间的键进行检查，如果发现键已过期，则删除该键。对于简单的字符串类型对象，如果设置了过期时间，在定期删除的执行周期内，即使键已经过期，由于还未被检查到，可能仍然可以被读取到，这就导致了在过期时间到真正删除之间存在一段时间的弱一致性。例如，设置一个字符串键key的过期时间为10秒，在第10秒时键逻辑上已过期，但如果定期删除机制还未检查到这个键，客户端仍然可以读取到该键的值。
2. 惰性删除：
   • 当客户端尝试读取一个键时，Redis会检查该键是否过期，如果过期则删除该键并返回空值。这意味着在键过期到客户端读取该键期间，键虽然在逻辑上已过期，但仍然存在于数据库中。比如一个设置了过期时间的字符串键key，过期后，在没有客户端读取它之前，它会一直存在于Redis中，这也体现了一定程度的弱一致性。