@yilisite 货拉拉技术团队对于遇到一些问题确实都会回馈到社区

@dvd888 贡献到 Apache 了，GitHub 地址: https://github.com/apache/incubator-kvrocks

嗯，是的。除了要求低延时的，中间还有很多高容量，但延时可以有一点妥协空间的场景。

嗯，其实我的意思是高可用不会依赖单机硬件，另外 Redis 数据全内存没问题，重启加载的 RDB/Aof 还是从磁盘恢复，所以也是同样的问题。

@bruce0 这个没关系，我们也是纯开源组织在维护项目，十分欢迎技术交流和讨论，不一定要使用项目。

@linksNoFound Redis 也是一样，靠复制和集群分配来解决可用性问题

@aper 之前 GitHub Discussion 上由一个讨论: https://github.com/KvrocksLabs/kvrocks/discussions/319

整体上，对于大多数可能关注的是功能的差异。除此了上面的讨论之外我自己觉得最重要的几个点:
* 社区是足够开放或者更加遵循开源准则，社区共识大于代码，尽量所有设计和讨论都在社区进行，包含 roadmap
* 对于代码的态度，至少 Kvrocks 不管在 PR 合并再 Commit Log 都是很严谨的讨论和对待
* 明确的 roadmap, 社区要有明确的方向，而不是走一步看一步

@zhengxiaowai wow ，太期待了~

@mekingname kvrocks 项目的 README 里面有一些 benchmark 数据，然后吞吐由于是多线程会比 Redis(包含 6.0 以上的多线程 IO)高，但读延时如果 miss cache 到磁盘肯定延时会比 Redis 高一些。本身是作为 Redis 的互补而不是替换，磁盘类型相比于 Redis, 单实例大小可以几百 G 同时成本基本是 Redis 1/10 以下。

@gabon cool, 如果没有加入 Kvrocks 社区交流群可以加我微信: hulkdev, 我拉你进群，现在超过 200 个人，只能邀请。

@wueryi @bruce0 可以看看 Kvrocks: https://github.com/KvrocksLabs/kvrocks

从项目活跃度、严谨性 (连 Commit Log 都是严格对待 )和社区讨论来说，应该是目前几个里面最好的。

这篇介绍的是 Kvrocks 的设计和实现: https://mp.weixin.qq.com/s/K9KVJR5sW7bsYrF4_dUV5g

@gabon Kvrocks 用户吗

GMP 可以帮忙做只是让并发更简单，而对于业务逻辑肯定是需要自己来做，比如控制最大并发。

请阅读完再来说？有啥区别？ 一个数据在磁盘，一个在内存，你觉得有什么区别？ 另外，实例数有千级别，够不够？

最后一条回复你，开源并不是求着你用。

另外，门槛低不低这个问题先不讨论，既然开源出来能够让百度、携程、白山云采用肯定是有自身的优势和设计理念，而不同设计做出来的系统当然也完全不是一回事。每个公司对于这方面的诉求不一样，就像 OS/Kernel 也同样一堆类似的选型，选择自己合适才是最重要。

包含发文章之前，我们也知道一定会有人想知道差异点是什么，选择不在里面去说明，主要是从我们角度来说，没办法完全保证客观去对比，所以更希望是有人抛出来的时候，再来公开的讨论而不是写在文章里面到处传播。

@zagfai 对于大部分公司来说，如果存储的数据量太小，确实不是瓶颈。很多公司的 Redis 集群回到百 G 甚至是 T 级别，那么成本和实例容量是一个比较大的挑战。而 MySQL 其实也是选择，但使用场景和性能不是一个维度的，比如很多业务就是一个简单的 KV + 过期场景，使用 MySQL 或者其他选型也不是问题，那么就需要业务去实现这些逻辑。

@airyland

pika 功能基本一样，有部分结构设计也来自 360 的 balckwidow 项目，然而为什么不直接使用 pika 的几个主要原因:

* Redis 语义兼容问题，我们希望更加接近 Redis 而不是每个类型都是独立的 DB
* 主从同步设计上，pika 使用 rsync 容易成为问题定位的黑盒，kvrocks 直接基于 rocksdb 的 checkpoint 来实现，同时我们同步时基于 RocksDB WAL 不是 binlog，不需要回放，所以同步性能也会更好
* 功能设计上，容量大之后意味着业务混用会变多，我们希望业务之间数据可以隔离，kvrocks 主要是通过 namespace 来实现
* profiling 能力，磁盘 kv 相比于内存 Redis 明显的问题是毛刺点会因为磁盘任务而增多，定位具体毛刺点的 profiling 能力就显得更加重要，我们通过允许对命令级别的慢请求进行 profiling 日志收集和输出，方便定位问题
* 代码质量，这个比较主观，这里不多说，有兴趣可以自己去看 看 kvrocks 、pika 代码

其他还比如为了解决全量 compaction 带来的毛刺点问题，我们也对自身 compaction 检查策略进行一些优化。Tendis 主要是集群方案过于复杂，真的不确定外部有多少公司真能用起来。

@zagfai 你可以你来，别看不懂开始喷

@acczefly 还没有呢，目前个别业务开始引入。不过整体代码比较简单且单元测试覆盖比较完整，没什么问题。