Pika项目中INCR命令与TTL结合导致的主从不一致问题解析

问题背景

在分布式键值存储系统Pika中，我们发现当使用带有TTL(生存时间)的INCR命令时，可能会引发主从节点数据不一致的问题。这个问题的本质在于主从节点之间命令传播的时间差与TTL机制的交互产生了预期外的行为。

问题现象具体分析

当在主节点执行以下操作序列时：

1. setex key1 10 value1 (设置key1值为100，10秒后过期)
2. incr key1 (将key1的值递增至101)

主节点会正确地将key1值更新为101，并且维持原有的10秒过期时间。然而问题出现在从节点同步过程中：

• 如果从节点在30秒后才收到这两条命令的binlog
• 第一条pksetat命令(对应setex)由于采用主节点的过期时间戳，从节点写入时key1已经过期
• 接着执行incr命令时，由于key1不存在，从节点会创建一个新的key1并赋值为1
• 结果导致主节点key1会在10秒后过期，而从节点的key1却永久存在

问题根源

这个问题源于两个关键因素的交织：

1. 命令的"无中生有"特性：INCR等命令在key不存在时会自动创建
2. TTL的绝对时间传播：过期时间是以绝对时间戳形式传播的

当从节点延迟处理binlog时，基于绝对时间的TTL机制与自动创建key的命令特性产生了冲突。

解决方案设计

经过深入分析，我们提出了优雅的解决方案：

对于会"无中生有"的命令(如INCR、APPEND等)，当操作带有TTL的key时，在生成binlog时需要将key的TTL信息一并携带。具体实现方式是将这些命令重写为pksetat形式的binlog。

以INCR命令为例：

1. 主节点执行incr key1时
2. 如果发现key1带有TTL且未过期
3. 则构造一个pksetat binlog，包含：
   • 新的值(原值+1)
   • 原有的过期时间戳
4. 从节点应用这个binlog时，会正确设置值和过期时间

影响范围评估

经过全面梳理，我们发现具有类似行为的命令还包括：

String类型：

• APPEND：追加值时若key不存在会自动创建
• INCRBY/DECR系列：与INCR类似

Hash类型：

• HINCRBY：哈希字段递增时若key不存在会自动创建
• HSET：设置字段时若key不存在会自动创建

其他类型：

• List的LPUSH/RPUSH
• Set的SADD/SMOVE
• ZSet的ZADD等

目前我们优先处理String和Hash类型的相关命令，其他类型的类似问题将在后续版本中逐步解决。

实现注意事项

在具体实现时需要注意：

1. TTL获取时机：必须在执行命令前获取key的TTL，因为命令执行可能会改变TTL
2. 原子性保证：TTL获取和命令执行需要保证原子性，避免竞态条件
3. 性能影响：额外的TTL查询可能会带来轻微性能开销，需要进行优化
4. 兼容性考虑：新的binlog格式需要保持向后兼容

总结

Pika中INCR与TTL结合导致的主从不一致问题，揭示了分布式系统中时间敏感操作与最终一致性之间的微妙平衡。通过将特定命令重写为携带TTL信息的pksetat形式，我们既解决了问题，又保持了系统的兼容性。这种解决方案不仅适用于当前发现的INCR命令问题，也为处理其他类似命令提供了可复用的模式。

对于分布式存储系统的开发者而言，这个案例提醒我们需要特别关注：

• 时间相关操作在分布式环境中的传播
• 命令的副作用在不同节点的表现
• 延迟处理可能引发的边界条件

通过系统性地解决这类问题，Pika在数据一致性方面又迈出了坚实的一步。