JIMDB：一个大规模分布式内存存储的演进之路

刘海峰：JIMDB是一个以内存为中心的键值数据库，目前在我们京东多个数据中心部署了几千台机器，支撑了京东几乎所有的在线业务。JIMDB的研发是一个逐步演进的过程，最初是从Redis改进而来，现在的数据模型是兼容但不仅限于Redis，可以理解为Redis的一个超集。JIMDB在京东的应用也不限于缓存，我们很多业务线已经把它当成唯一的存储。

具体来说，研发过程经历了三个阶段：

• 第一个阶段是从2013年底开始。当时我们在使用Redis时遇到了一些问题，为了解决这些问题，我们把Redis这个优秀的单机软件变成一个健壮的分布式系统。比如我们要做故障的手动、自动切换；要实现横向扩展，动态分片并且不能影响网络流量；要实现灵活的异步复制、同步复制。虽然每个实例仍然是单个的Redis，但整个的集群能够实现故障的切换、横向的扩展和比较灵活的复制。

• 第二个阶段从2014年下半年开始。用一句话来概括这个阶段就是把JIMDB变成了一个完全托管、自管理、自运维的存储服务。因为Redis的引擎比较简单，为了实现这个目标，我们重写了整个内存存储的引擎，使之可以支持更细粒度的分片；复制协议部分也作了改动，不但支持全量复制、增量复制，还支持了任意局部复制。例如，我们经常遇到某个分片上的热数据过载的问题，这时候的解决方案是把这部分数据复制到其他的实例上，从而分散流量，这样我们就实现了动态的分裂、合并。在运维管理上我们引入了Docker，部署环节实现了整体的调度。

• 第三个阶段在2015年上半年启动规划，目前这个阶段还在进行中。我们已经把很多实现陆续推到了线上。即，不仅仅支持原来的哈希分片和原有的数据类型，我们还实现了在内存中支持毕加树、支持按范围的划分、支持排序的遍历、复制协议也更健壮、更可靠，等等。第三阶段实现的特性将比Redis更加强大。当一个分布式存储支持按范围分片和复制的时候，这个系统无疑是更健壮和更可靠的。当然，这个阶段也存在很多的挑战，例如，哈希的分片相对来说比较简单，但我们要实现按范围、跨数据中心的异步和同步复制时，这个挑战就大的多了。

纵观这两年的发展，JIMDB从最初的几台服务器到现在的几千台、从单机Redis系统到自管理的分布式存储系统、用户只需要一个认证授权即可使用、支持京东线上一千多个业务（集群），是一个不断挑战的过程。

刘海峰：这更多的是业务的需求。公司原来的存储应用百花齐放，有人用Redis、有人用MongoDB、有人用memcached等等。但现在的情况是，数据库用MySQL比较多；NoSQL几乎99%的都在用JIMDB。原因在于JIMDB有人维护、自管理、性能稳定，俨然已成为京东内部垄断性的应用。但在项目开始的时候我们也没想到会变成今天的规模，随着业务的发展，JIMDB一步一步演进成了今天的样子。

刘海峰：目前JIMDB的应用场景十分广泛。比如，现在依然有很多同事把JIMDB当Redis来用，很多人拿来当缓存用，也有很多人把JIMDB当唯一存储在用，用法不一而足。甚至，很多离线计算MapReduce的结果也直接存在JIMDB里；对京东的访问用户来说，大家看到的商品详情整个页面的所有元素、第三方show的广告、搜索推荐的结果等等，都是存在JIMDB里面。我们支撑了无线端、PC端很多业务。但总的来说，目前用量最大的业务是搜索和推荐的集群，另外单品页的用量也很大。因此这个系统的压力也很大。

跟其他内存存储相比，首先这个系统是从Redis演进过来的，Redis有的功能我都有，但是JIMDB在很多方面都比Redis更健壮、更稳定。其次，从Redis的视角来说，这是一个经过大规模生产环境验证的、更好的Redis。目前我们有六、七个人在维护这个系统。

刘海峰：持久化还是采用经典的方式——记日志、定期做快照。虽然这是一个很简单的方式，但是十分的有效。对于可预测的热数据我们会预先做分片，尤其是秒杀活动的内容；而对瞬时的热数据做动态调整是JIMDB最优先的特性实现，这跟我们电商的特性相关。目前京东的老机房大量部署了JIMDB，新机房也部署了很多。

算法和数据结构方面，刚才已经举过一个例子就是毕加树。我们实现了KV的有序排列和按任意范围的分割、复制。这是我们新加的数据类型，其他的支持已经十分强有力了。

刘海峰：这一方面主要做的工作是内存分配器的优化。Redis的内存分配器是 jemalloc ，我们依然沿用了jemalloc，但是我们作了很多优化。此外，我们对比较大的Value做了特殊处理，比如我们不让大Value的存储占据内存，而把它写到磁盘中去。但是很多人会问SSD的问题，为什么不采用混合存储的架构？

其实在2014年的时候我们专门在线上测试过这个方案，当时大概对10%的集群采用了混合存储的方案。经过一段时间的测试发现：

• 首先，虽然SSD的成本有一定的优势，但实施工程是有成本的。基于磁盘去写一个有丰富类型的键值数据库其实是比较复杂的，即使是简单的键值都比较复杂，在遇到Map、List、毕加树等等，用磁盘的方式实现起来其实更为负责、成本更高。也就是说，其实现和维护的成本太高，并且性能也不占优，整体工程成本远远超过内存存储。

• 第二个原因在于，内存的价格在逐渐降低，我们是能承受这个成本的。目前我们使用的内存也越来越大，预计明年我们将在单机上使用1T的内存。

• 第三个原因是系统架构方面的考虑。我们的数据中心有很多的机器，很多应用服务器和私有云服务器多数时候的内存利用率并不高，我们可以利用这些机器的资源做JIMDB的动态资源池，只需要在相应的机器上部署一个JIMDB的程序就好。这也极大地提高了整个数据中心的资源利用率。

基于以上三点考虑，我们选择用内存做存储。随着京东业务的发展，未来1～2年我们JIMDB的规模将达到1万台机器，当然，这1万台机器并不是专用的，而是JIMDB在整个数据中心的部署量。

刘海峰：JIMDB在“双11”的表现很好，系统稳定，性能平稳。我们的新机房启用了大量万兆网卡，以前千兆网卡被打满的情况终于得到缓解。但任何系统都不可能没有任何瑕疵，现在看来JIMDB的问题更多的不是技术性的，而是系统到了一定量级怎么去运维，尤其是系统预警和运维操作流程方面的工作需要加强。随着公司业务的发展，运维正变得越来越重要。

我们花了很多精力来做监控与运维。JIMDB核心的部分是一个个兼容Redis协议的Server，除了网络部分，我们几乎重写了整个存储引擎。还是拿一个具体的应用场景来说吧，假设我一台机器上跑了15个实例，但是发现其中一个实例的流量极大，把其他实例的带宽都给占了。这个时候我需要对这个有问题的实例进行分裂和迁移。但是迁移的时候存在一个问题，由于进出流量都很大，迁移有可能是迁不动的。这个时候我们有一个限流措施，保证在不影响其他实例带宽的情况下把有问题的实例迁走。

刘海峰：我非常坚信的一点是， 内存是存储的未来 ，特别是对一些有结构化的数据来说。随着内存成本的降低，以及在内存上实现存储的简洁和高效，这个趋势势不可挡。而且我认为JIMDB这两年做的工作是一种更务实的RAMCloud实现，它是业务驱动的、经过大规模生产环境验证的。

未来随着系统的发展，在功能上我们会以内存为中心，做有序的、KeyValue的、丰富数据类型的大表支持。JIMDB未来有可能会加入一些SQL的支持。目前要先把规模、稳定和运维做好。