Kvrocks: 一款开源的企业级磁盘KV存储服务

Kvrocks 是基于 RocksDB 之上兼容 Redis 协议的 NoSQL 存储服务，设计目标是提供一个低成本以及大容量的 Redis 服务，作为 Redis 在大数据量场景的互补服务，选择兼容 Redis 协议是因为简单易用且业务迁移成本低。目前线上使用的公司包含: 美图、携程、百度以及白山云等，在线上经过两年多大规模实例的验证。

项目核心功能包含:

• 兼容 Redis 协议

• 支持主从复制

• 支持通过 Namespace 隔离不同业务的数据

• 高可用，支持 Redis Sentinel 自动主从切换

• 集群模式 (进行中，预计在 7-8 月份完成)

GitHub地址：https://github.com/KvrocksLabs/kvrocks

实现方案对比

除了 Kvrocks 之外，社区也有一些类似的基于磁盘存储兼容 Redis 协议的开源产品，从存储设计来看可以分为几类:

1. 基于磁盘 KV 存储引擎(比如 RocksDB/LevelDB) 实现 Redis 协议

2. 基于 Redis 存储之上将冷数据交换到磁盘(类似早期 Redis VM 的方案)

3. 基于分布式 KV(比如 TiKV) 实现 Redis 协议代理，本地不做存储

方案 1: 是基于磁盘 KV 之上兼容 Redis 协议，绝大多数的本地磁盘 KV 只提供最简单的 Get/Set/Delete 方法，对于 Hash/Set/ZSet/List/Bitmap 等数据结构需要基于磁盘 KV 之上去实现。优点是可以规避下面方案 2 里提到的大 Key 问题，缺点是实现工作量大一些。

方案 2: 基于 Redis 把冷数据交换磁盘是以 Key 作为最小单元，在大 Key 的场景下会有比较大的挑战。交换大 Key 到磁盘会有严重读写放大，如果是读可能会导致整个服务不可用，所以这种实现只能限制 Value 大小，优点在于实现简单且可按照 Key 维度来做冷热数据分离。

方案 3: 是基于分布式 KV 之上实现 Redis 协议，最大的区别在于所以的操作都是通过网络。这种实现方式最大优点是只需要实现 Redis 协议的部分，服务本身是无状态的，无须考虑数据复制以及扩展性的问题。缺点也比较明显，因为所有的命令都是通过网络 IO，对于非 String 类型的读写一般都是需要多次网络 IO 且需要通过事务来保证原子，从而在延时和性能上都会比方案 1 和 2 差不少。

Kvrocks 设计的初衷是作为 Redis 场景的互补，低成本、低延时和高吞吐是最重要的设计目标。基于 Redis 实现冷热数据交换的方式在大 Key 场景下可能导致不可用，从而需要限制单个 Key 大小，这个对于我们想实现一个通用的 NoSQL 存储服务是无法接受的。而对于方案 3 这种远程存储的方案，延时和吞吐一定是无法满足预期，所以我们最终选择的方案 1 这种基于磁盘 KV 之上实现 Redis 协议以及复制。除了数据存储方式之外， Kvrocks 并没有淘汰策略，所以一般是作为存储服务而不是缓存，当写入的数据量达到实例最大容量或者磁盘容量不足时会写入失败。

性能

需要注意的是以下提供的性能数据是基于特定的配置进行压测，不同配置会有比较大的差异。压测的硬件以及 Kvrocks 配置说明可参考: https://github.com/KvrocksLabs/kvrocks#performance

这里提供性能数据只是为了给读者更加直观了解 Kvrocks 的性能情况，大部分命令由于可多线程并行执行，从 QPS 的维度来看会比 Redis 更好一些&