OpenAtomFoundation/pika项目中ZSet Score Key版本比较Bug分析

问题背景

在OpenAtomFoundation/pika项目的3.5.3版本中，发现了一个关于ZSet(有序集合)Score Key比较器的Bug。这个Bug涉及到RocksDB中int类型值的存储方式与版本号(version)比较的问题。

技术细节

原有实现的问题

在原有实现中，blackwidow模块将int类型值使用小端(Little-Endian)方式存储到RocksDB中。这种存储方式导致了一个关键问题：无法按照字典序对版本号进行正确排序。

具体来说，在ZSetsScoreKeyComparatorImpl比较器中，是将主键(pkey)和版本号(version)统一作为前缀进行比较。这种比较方式对于版本号的比对是不正确的，可能会导致以下问题：

1. 遍历时获取到额外的、不应该出现的数据
2. 版本号比较结果不符合预期
3. 数据排序出现异常

问题根源

问题的根本原因在于存储方式与比较方式的不匹配：

1. 存储方式：int类型的版本号使用小端存储
2. 比较方式：却按照字典序进行比对

这种不匹配导致比较结果与实际的数值大小关系不一致。

解决方案

正确的实现应该是：

1. 如果保持int类型的小端存储方式不变
2. 那么在比较时应该先将版本号解码出来
3. 然后比较实际的int值，而不是直接按照字典序比对

这种修改可以确保：

• 版本号比较结果与数值大小一致
• 遍历操作能正确获取预期范围内的数据
• 数据排序符合业务预期

影响范围

这个Bug主要影响以下场景：

1. 同一个主键(pkey)下的有序集合数据
2. 频繁修改导致版本号变化的键
3. 涉及版本号比较的遍历操作

对于不涉及版本号比较的场景，或者不同主键间的比较，这个Bug不会产生影响。

总结

这个Bug揭示了在数据库系统中，数据存储格式与比较逻辑必须严格匹配的重要性。特别是在使用像RocksDB这样的键值存储引擎时，自定义比较器的实现需要特别小心，确保与数据的实际编码方式一致。

修复这个Bug不仅解决了当前的问题，也为系统在版本管理和数据遍历方面的正确性提供了保障。对于使用pika的开发者来说，升级到修复后的版本可以避免因版本比较错误导致的数据访问异常问题。