开源的基于 SSD 的 Redis 实现以及任务队列

[hulk]

美图基础服务团队这几天开源了两个项目:

• https://github.com/meitu/kvrocks 这个是基于 rocksdb 之上实现 Redis 协议和数据结构的存储

• https://github.com/meitu/lmstfy 基于 Redis ZSet/List 实现的 Task(Job) Queue

kvrocks

kvrocks 类似的实现主要之前 Qihoo360 开源的 pika 以及 SSDB, 至于为什么还要自己再造个轮子的主要原因如下:

• 依赖管理，我们更期望使用外部已开源且成熟的库

比如网络库 libevent

• 实现设计理念差异

比如 pika 使用 rsync 做全量同步，我个人觉得这个东西有问题很难定位又不好解决，当然使用 rysnc 优点是很简单另外又具备很重要的功能就是断点续传。但在我们的实现中，这部分自己基于 rocksdb 的 bakcup 来做实际上也是很简单

• 功能设计的一些差异点

比如 pika 把多种数据结构实现在多个 rocksdb 的 column family 以来提高性能，而我们认为这块 key 的唯一性不应该牺牲，会给业务带来困扰。另外，我们通过 namespace 的方式来支持不同业务共用一个实例，而数据是隔离的。还有类似 bitmap 实现上，pika 最大支持 128 KB, 而实际业务使用中这个远远不够, 我们也进行了重新设计

*希望代码更加简洁和规范(这个点完全是主观想法，需要自己判断)

实际上，我们其实更希望不要去造这种重复的轮子，但基于以上几个诉求基于 pika 去做一些改造对我们来说，不管成本和可行性来说远不如按照自己的想法去实现。另外，这个东西的门槛，我自己认为是在完全把控 rocksdb 而不是上层实现。我们的数据结构设计上大部分是借鉴自 pika 的 blackwisdow, 十分感谢 pika。我们也希望我们可以给大家提供除了 pika 之外的另外一个选型，完全不是坏事。

kvrocks 目前在美图这边已经有不少业务在使用，目前在公司内部已经上线半年左右且接入了不少业务

LMSTFY(Let Me Schedule Task For You)

至于 Task(Job) Queue 这个目前我们知道的几个队列的选型, 比如: beanstalkd, disque, celery(这个应该算 client 端的任务队列)。beanstalkd 主要问题是没有复制导致服务单点，数据可靠通过 WAL 持久化到磁盘, 数据量大时恢复时间会过长，现在项目也不够活跃了。disque 是 redis 作者开源的另外一个项目，这个本是一个很好的选择，但 Redis 作者预期将这个功能集成到 Redis Module 且项目不再维护，短时间来看这个功能还没有集成到 Redis Module 里面。所以我们后续选择基于 Redis 实现 Task Queue 的功能，且支持通过 token 来支持 Redis 多集群从而支持容量的扩展，具体大家可以看项目的 README。

我们后续也会有专门的文章来详细说明这两个东西的设计考虑点和实现

[julyclyde]

想起了十年前，家家都有 memcached-db
五年前家家都有 dpdk based LVS fullNAT