PokIsemaine commented on issue #2162: URL: https://github.com/apache/kvrocks/issues/2162#issuecomment-2132039501
> 之前有提到过 Redis 的事务隔离级别是 Serializable（序列化），那么想做到完全的兼容就必须保持一致。内存数据库和传统基于磁盘的数据库在体系结构上有很大的区别。内存事务不会涉及到 IO 操作，性能瓶颈就从磁盘转移到了 CPU 上。比较成熟的并发协议有：轻量锁、时间戳、多版本、串行等方式。大多数的 Redis 兼容服务还是采用了轻量锁的方案，这样比较容易做到兼容，Dragonfly 的实现是参考了《VLL: a lock manager redesign for main memory database systems》[[7]](https://zhuanlan.zhihu.com/p/584485562#ref_7)里的 VLL 方案。不过从支持的接口[[8]](https://zhuanlan.zhihu.com/p/584485562#ref_8)列表看，Dragonfly 尚未完全兼容 Redis 的接口。 * kvrocks 现在使用了 `src/common/lock_manager.h` 中的 `LockManager`，这个现在是瓶颈所在吗？因为 kvrocks 并不是 in memory database，我们是否有必要重新设计一个轻量级锁方案？ * 同时我看到参考文献里提到并发引擎的 HashMap 应该支持 「渐进式 rehash」以及「并发修改过程中的无状态扫描」，这两点 kvrocks 现在是支持的吗？或者有必要支持吗？ * 现在 kvrocks 隔离级别并没有达到 Serializable，正在尝试的新 Context 机制暂时也只是期望达到 Snapshot 隔离级别。结合 Context + LockManager 之后，我们距离 Serializable 还有哪些问题？ > It was mentioned before that the transaction isolation level of Redis is Serializable (serialization), so it must be consistent if you want to be fully compatible. There is a big architectural difference between in-memory databases and traditional disk-based databases. Memory transactions do not involve IO operations, and the performance bottleneck is transferred from the disk to the CPU. More mature concurrency protocols include: lightweight locks, timestamps, multi-versions, serialization, etc. Most Redis compatible services still use lightweight lock solutions, which are easier to achieve compatibility. The implementation of Dragonfly refers to "VLL: a lock manager redesign for main memory database systems" [[7]](https://zhuanlan.zhihu.com/p/584485562#ref_7) VLL solution. However, judging from the list of supported interfaces [[8]](https://zhuanlan.zhihu.com/p/584485562#ref_8), Dragonfly is not yet fully compatible with the Redis interface. * kvrocks now uses the `LockManager` in `src/common/lock_manager.h`. Is this the bottleneck now? Because kvrocks is not in memory database, is it necessary for us to redesign a lightweight lock scheme？ * At the same time, I saw in the reference article that the HashMap of the concurrent engine should support "progressive rehash" and "stateless scanning during concurrent modifications." Are these two points supported by kvrocks now? Or is support necessary? * The current isolation level of kvrocks has not reached Serializable, and the new Context mechanism being tried is only expected to reach the Snapshot isolation level for the time being. After combining Context + LockManager, what problems do we have with Serializable? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
