KV开源组件选型对比

KV开源组件选型对比

1、 背景

我司对缓存的需求场景可细分为两种：高性能低延迟小容量的内存型缓存，低性能高延迟大容量。利用大容量KV存储替换掉性能需求范围内的内存型缓存，可以节约大量的成本，也是目前多家互联网厂商所选择的技术路线。利用目前逐渐成熟的开源KV存储产品为基础建设我司大容量KV存储服务。

本文档评估对比目前开源的KV存储产品的能力，为我司KV存储产品发展路线提供决策依据。

2、 候选列表

通过在github、gitee开源网站上排查，排除个人背景的KV存储产品，选择了四个公司研发背景的KV存储组件进行对比。

3、 对比维度

对比按照按照以下七个维度，每个维度按照优良中差进行评分

4 详细论证

4.1 Redis兼容性

1、 兼容Redis的RESP通信协议

论证：Pika、Tendis、KVrocks都是以无缝替换Redis设计，按照Redis的RESP协议开发了交互接口；开源版Tair是阿里巴巴公司自研的缓存组件，没有使用Redis的RESP协议，因此兼容性最差

2、 兼容Redis的API

Pika、Tendis、KVrocks实现了Redis的大部分API接口，且API的行为一致，其中Tendis的兼容API最多，Pika次之。

3、 集群模式兼容度

Pika

Pika不支持Redis官方的Cluster模式，支持Codis、Twemproxy两种集群方式。即采用代理协助分片，客户端发送请求到一个可以理解 Redis 协议的代理上，而不是直接发送请求到 Pika 实例上。代理会根据配置好的分片模式，来保证转发我们的请求到正确的 Pika 实例。

Codis+Pika(sharding模式):Pika利用自身独立的rocksdb实例来实现按照分片slot存储数据（对于某一个KEY的数据存储在哪个分片中是由算法决定），分片在Pika上的物理存在形式也是文件目录。比如DB0有10个分片分别为0,1,2,...,9，那么在目录db0下就会有10个文件子目录分别是:0/,1/,...,9/。Codis官方版本默认1024slots分片，将Codis初始化后的slots信息添加到Pika实例中，可实现集群动态扩缩容（以slot为单位的迁移），由于Pika的slot在物理上以文件目录的形式存在(类似一个rocksdb实例存储)，相对于Codis-Redis扩容使用以key为单位做迁移来说要快的多。迁移一个slot相当于移动一个文件目录。解决了在数据量巨大时扩容、迁移时间过长的问题。

twemproxy+Pika(sharding模式)：twemproxy支持的hash算法非常多，crc32a&modula是Pika目前支持的哈希取模的数据分布方式，twemproxy 根据具体的server数量进行哈希，例如server数量是4，哈希取模的结果如果是0，key落到server1上，对于server1 Pika1来说对于key还要重新哈希取模，判断这个key是否属于现有的slots。如果Pika哈希取模的结果也是0，并且Pika1拥有slot 0，那么Pika将对该key进行处理。

Tendis

类似于Redis Cluster, Tendis存储版使用去中心化的集群管理架构。数据节点之间通过gossip协议通讯，用户访问集群中的任意数据节，请求都能路由到正确的节点。并且集群节点支持自动发现、故障探测、自动故障切换、数据搬迁等能力，极大降低运维成本。

优点：

所有数据存储到磁盘，提供更大的容量和更低的成本，数据可靠性更高

多线程架构，单进程的性能吞吐比redis单进程更高（30wQPS vs 13wQPS）

独立的gossip网络线程，支持更多的节点通讯，支持更大规模的集群（支持扩展至1000个节点）

更强大的数据搬迁能力，原redis cluster的搬key实现，如果遇到大key，会导致比较恶劣的全局阻塞

基于rocksdb的镜像和完善的binlog实现，支持任意时间点的回档，社区版redis暂无这个能力

支持增量复制及复制断开断点续传，redis复制断开需要全量复制

缺点：

对比纯内存的redis，Tendis存储版的延时更大

部分命令还不支持（LUA, pubsub, geo等），正在完善中

对于单key更新，由于Tendis存储版内部并发控制，无法发挥多线程的优势，会退化为单线程，性能较低

参考：http://tendis.cn/#/Tendisplus/%E6%95%B4%E4%BD%93%E4%BB%8B%E7%BB%8D/%E5%AF%B9%E6%AF%94

4、主从复制和高可用

Pika

Pika可通过slaveof命令搭建复制及取消复制，搭建后数据复制正常，通过config rewrite可以将配置持久化到本地配置文件，但缺乏Redis中类似 debug digest命令检查数据一致性，可通过使用info keyspace 1异步扫描获取keyspace数量。

Pika不支持级联复制，即Pika的主执行slaveof 新主时直接报错:

Pika能够配合Redis-sentinel(哨兵)实现自动容灾切主, 使用方式与redis完全一致。

需要注意的是：

1、 Pika目前并无server-uuid, 但这并不会对哨兵的运行造成影响。

2、 Pika由于没有运行id，执行slaveof只通过offset判断增量和全量，可能会有以下问题：

场景一

SERVER2: SLAVEOF SERVER1

SERVER2: SLAVEOF NO ONE

SERVER2: SET test test

SERVER2: SLAVEOF SERVER1

SERVER2: INFO

且日志出现同步错误

解决方案：SERVER2: SLAVEOF SERVER1 force 强制进行全量。

场景二

SERVER2: SLAVEOF SERVER1

SERVER2: SLAVEOF NO ONE

SERVER2: SET test 222

SERVER1: SET test 111

SERVER2: SLAVEOF SERVER1

SERVER2: INFO

SERVER2: get test 得到222

SERVER1: get test 得到111

参考issue：https://github.com/OpenAtomFoundation/Pika/issues/893

解决方案：SERVER2: SLAVEOF SERVER1 force 强制进行全量。

3、 Pika不支持rename command功能因此识别不了哨兵发送的myconfig命令，导致主从切换后Pika.conf中slaveof配置未及时更新和实际主从不一致情景，在特定场景下（比如主从同时启动）可能导致主从复制异常。

4、 如果切换时主从数据一致，正常主从切换后Pika是增量同步。如果不一致，由于搭建哨兵发送的是slaveof命令，因此可能发生类似问题2同步失败问题。

参考：https://github.com/OpenAtomFoundation/Pika/issues/909

Tendis

slaveof命令用于设置主从复制关系。

slaveof host port：用于设置当前实例为指定实例的从属实例。跟原生redis不同，为了防止错误操作，如果当前实例已经是从属实例了，再次设置为其他实例的从属实例时会返回错误。另外，如果当前实例有数据，也会返回失败，需要执行flushall之后再设置。

Tendis支持级联复制：A->B->C

slaveof no one：用于断开主从关系。

Tendis不支持Sentinel集群搭建高可用，主动failover及shutdown都不能进行主从切换。

4.2 Sedis兼容性

TODO

4.3 性能

TODO：依赖SSD资源池

4.4 特有功能

4.5 稳定性

TODO：功能测试？

4.6 开源活跃度

4.7 未来演进