京东云平台总架构师、系统技术部负责人刘海锋：从2014到2016，大规模内存数据库演进之路

2015中国大数据技术大会首日全体会议中，京东云平台总架构师、系统技术部负责人刘海锋带来了名为“大规模内存数据库JIMDB：从2014到2016”的主题演讲。“Memory is the new disk”，JIMDB基于redis，以内存为中心的数据存储，其底层技术研发包括了存储引擎（Dict、LSM with RAM-SSD hybrid、B+Tree）、复制协议（async、sync等）、分片策略（Hash、Range）三个部分。过去两年，JIMDB一直持续建设，拥有着数千台大内存机器，多个数据中心，1000+线上集群，支撑了京东几乎所有的业务。

京东云平台总架构师、系统技术部负责人 刘海锋

以下为演讲实录

刘海锋：

各位同行朋友，大家下午好！非常高兴来到BDTC跟大家做交流。我今天要给大家分享的是大规模的以内存为中心的新型数据库——JIMDB，包括它过去两年的历程、技术脉络以及是怎么支撑起京东的典型电商业务。

刚才Databricks公司联合创始人、Spark首席架构师辛湜分享了Spark演进历程，它是以内存为中心的分布式计算系统，到Spark最关心的创新是以磁盘为中心演进至以内存计算为中心，从计算领域是这样。而从我个人角度也非常坚信，存储依然会有这样的趋势。这个观点是过去两年工作中，和我的团队在实践中得到的很深刻的体会。今天在这里做个简单分享，希望对大家有参考价值。

电商不仅仅是大数据驱动的，我们用大数据为用户、商品等带来运营效率的提升。同时，从在线的数据访问来讲，电商业务需要非常快速的数据访问。大家可以看到，我们随便打开京东首页或类似的电商首页，图片是我们的资产，是商品形象的描述，可以用CDN加速。除了图片之外，其他几乎都是动态内容，量很大，且是频繁被改写的，它们需要非常快速的访问，比如说商品的详情、价格、品类下推荐的结果等许多内容，打开个商品详情页面或列表页，后台逻辑是很复杂的，需要非常多的数据去展现。

这个过程中，一个是快速的数据访问对终端用户的体验有非常关键的影响。另外，从我们产品工程师开发的产品角度出发，另一个诉求就是关注业务逻辑，而不应该花时间优化后台在线存储的性能。Jim Gray是数据库领域的泰斗级人物，他其中一句话我记得很清楚，即“Memory is the new disk（内存是新的磁盘）”。07、08年时我们买的内存大小标准配置是4G左右，很快4G、8G、16G一路下来，很多公司都会采购158、265G内存，估计明年都会用1T内存。我们都用265G内存加万兆网卡来做，单机内存在快速变大，整体很多在线的小结构和半结构化数据存放在内存里，这个问题是不大的，也是非常合理的。而且用内存做在线存储确实有弊端，就是成本在一个时间段内有些偏高，但是除此之外却带来很多性能、管理等各方面的便捷性，两相权衡下，在一定程度上，成本的升高对有一定规模和业务比较重要的公司可以接受，而且我们可以用技术手段降低这个成本。

JIMDB的全称为The Jingdong In-Memory Database，这个系统的名字是我在大概2014年初起的，它并不是严格的关系型数据库，而是一种新型的，以内存为中心的全部托管、全管理服务化的数据库。它是以内存为中心的数据存储，主要针对在线的结构或半结构化的数据，过去两年一直在持续建设。从目前的业务价值角度，它支撑了京东几乎所有的在线业务。除图片之外，几乎所有的动态内容都被它所服务，或者严格来说，图片的有些信息也用它来存储。越来越呈现一个趋势，就是我们更多地用它来做主存储，MySQL或者DataBase会进行归档。

接下来我从技术角度做个简单介绍。JIMDB基于redis，redis是一个非常优秀的开源软件，它做对了两个事情。第一，它是基于内存的，简单且高性能；第二，也是基于内存，它提供了非常丰富的数据类型和数据结构。对许多互联网公司来说非常方便，比如商品的详情、属性等，非常便捷。两年前，我们为了解决它的痛点，因为之前的监控系统已不能满足我们的业务需求，便不断演进，一路做下来。

Build a distributed system

它是相对分散的分布式系统，有许多分支、模块，不同模块做不同的事情。从用户（业务的开发人员）的角度，给他们提供Java、C driver，其他小众语言是给他们提供代理，完全兼容但是不限于RAM servers 。对于任何一个业务都给它集群，所有集群都在我们的物理资源池上。我们这个团队的核心任务是做一套复杂的平台，一套健壮的分布式系统，管理目前大概四五千台大内存机器，为众多业务提供可靠的、性能稳定的、数据有持久性保证的高可用服务。

这个系统从部署结构来讲，是单个物理服务器、多实力的结构，任何大内存物理servers上都会部署多个内存，好处是便于流量监控等，但是给业务和监控带来很多复杂性。对行业来说目前还是比较合理，故障的检测与切换，扩容的管理、升级、监控等都是独立的模块。存储的servers是复用原来redis网络编程的框架，但是复制的协议、存储的引擎等各方面都是自己来开发。

在此列举几个技术点。第一，怎么做故障切换？分布式系统要解决的第一个问题是怎么处理故障。故障是个很严肃的事情，并不能简单说有一个进程有一个servers不通了就是故障，会发生网络不稳定等等，各个方面都有可能。在一个或多个数据中心有若干个故障检测器，当多数人认为它故障并且没有人认为它健康时，才能定位确实故障。发给故障的控制器做下一步事情，重新触发新的配置，改变集群的拓扑。所以故障的检测和自动的Failover是2014年做的第一个事情，把故障自动化，这个事情说起来简单，其实是最基础和最重要的，因为整个过程分很多步骤，前一段时间还出现过Bug。

第二个关键问题是任何一个逻辑的集群、业务数据量会增长、变化，所以必须支持在线、动态、重新的分片，或者说重新的Sharding，这个Sharding核心思想不是简单把集群分片，中间要加一个抽象，才能进行动态的重新分片。对于这个策略来说，中间加一个bucket的抽象，然后来进行管理。迁移的过程是通过复制来做的，学术界或工程界喜欢管它叫“Partial replication”。举例来说，原来是3个分片，现在怎么变成4个分片？通过调度算法，决策把哪些分片中的bucket迁移到这里，迁移是通过复制来做的，建一个复制关系，但是这个复制关系并不是复制它原来所有的数据，所以要求复制协议的实现是要做特殊的事情，只要这一个区间的复制，复制全部完成之后更改拓扑，最后生效，这可以做并行的Partial replication做迁移。从数据的可靠性保证比较高，技术也比较简单和传统。

过去两年从底层技术研发分三个方面一步步演进做了些事情，从存储引擎的角度，用的最多的是这个，第二个存储引擎是LSM，我们用RAM+SSD做混合的两级存储，这三种不是取代的关系，而是互为补充。第二种更多应用的场景，是有些东西比较大，我们可以把这个放在SSD上，把K依然放在RAM里，这样可以适当的节省成本，目前第二类线上已经有百分之十几的用量，但是数据量要乘四五倍，因为每台机器单机容量更大。第三类是B+TREE，可以排序，可以支持按范围查找和便利，这个线上用得不是特别多，我们只支持有需要按范围、需要便利查询的场景。

复制协议更加关键，因为对于存储来说最核心的是复制，除了异步复制就是同步复制，我们上半年做了状态机的复制。分片策略我们用哈希最多，因为哈希最简单，业务更多时候需要单K去查询，有些业务需要按范围，我们支持Range。这三个方面技术可以做合理的按业务场景组合，满足不同的业务需求，比如业务更多是用Dict+异步复制+哈希分片策略，比较大的是RAM+SSD两级存储，然后配合其他的策略。

从业务使用场景角度，我们是分而治之，不同的软件、不同的集群，根据业务的需要，可以分成这么两大类。不少业务是做纯缓存，后台还有数据库和其他存储，我们更多是用异步复制或者不复制，哈希的分片，可以做LUR的淘汰。但是线上也有将近一半左右的集群，他们不仅仅用这个东西做缓存，他们做持久存储，我们有更高的可靠性保证，一般用来开启同步或者状态机的复制，然后用范围或哈希分片，而且对它的快照做定时备份，备份到内部对象存储上去。

对任何一个系统来说，底层的基础技术研发仅仅是它的一个环节，当系统达到一定规模之后，更多工作会放在监控和运维体系的建设方面。整个平台我们有比较完善的监控体系，这更多是数据驱动的，从各个方面，连接树、网络入出流量等等，产生很多时间序列进行分析、预警，并且驱动各种控制器做决策。比如有的分片存的数据因为是个华为的手机，它太热了，我们就可以把它做分列，很多时候做扩容做分列并不是因为容量，而是因为数据的热度。数据监控也存在这个系统里做快速的展现。

基于容器的自动化运维，因为我刚才说过，整个系统规模比较大，有几千台机器，而且每台机器上部署很多的存储节点，所以运维的复杂性比较高。在整个2013年更多是依靠手工的运维，怎么样选机器，怎么样部署，运维工作量极大，在2014年下半年和2015年上半年，我们花了很长时间做全自动化运维的平台，它是基于Docker，简单来说是大的Linux大内存服务器上上面有很多Docker，每个进程是Docker实例，用Docker软件管理版本，智能做机器的选择，做定期的软件升级，各个方面很多工作。这个平台通过容器技术也在这里面有所发挥。

说一说规模吧，因为对于任何一个底层系统建设来说，它核心的价值只有一定规模、真实驱动业务才能有收获力。线上我们有多个数据中心，有几千台大内存机器，都需要跨数据中心的复制，有的基于容灾的考虑，比如不同的机房有不同的规则，有可能跨机房做异步复制，有可能同步，预计明年有512G内存或者1T内存机器的采购。线上支持了1000多个线上的业务，每个应用相当于一个逻辑的集群。从运维角度来说，这么多台机器里面有大概3万多Docker的实例。

内存存储带来什么？花了很多内存片、内存条，带来了极佳的性能、非常稳定的性能，这是我们线上某一个比较重要的集群，在双十一期间可以看到它整体的QPS超过200多万，是非常稳定的，99%的请求都在2毫秒之内返回，这个让用户体验更好，让我们的业务开发起来更加简单，让公司运维团队更加省心、更加轻松。

内存存储考虑的一个主要因素是，内存可以花钱买，但是不能因为软件因素再去浪费内存，内存存储是分出来的，线上很多集群比较夸张、比较大，可能因为它使用场景比较特殊，才产生了碎片。但是整个分布来说，我们也做一些优化的工作，从内存分布器选择来看，主要的集群内存碎片率基本在1.1-1.3左右。我个人工程上的经验来说，这是非常好的内存分配器，内存分配器自行开发意义很小。

正在做的事情比较多，优先级比较高的是让它更稳定更好的运维，除此之外进一步提升性能，通过软件硬件协同创新，引入更大、更便宜的内存、更快的网卡，考虑重新实现用户的网络协议加速小包的处理性能。Linux网络协议站不是为数据中心高速的网络、高速的在线应用而设计，每一次包都要中断，对于大包是合理的，对于小包是不划算的，这样的存储性能更多的是小包处理，我们在考虑重写用户协议，来加速小包处理的性能。在功能方面我们也在做个事情，这更多是工作量的事情，考虑从NoSQL支持SQL接口，因为底层有了横向扩张、灵活复制的内存里的数据结构的存储。通过JAVA等等提供，这是工作量的问题而已。

另外，希望在某种程度上降低成本，因为平台化第一步是求规模稳定，让它有很好的性能和效率的保证，第二是从整体来说能降低成本，比大家分散、自由去用更省钱。基本的想法是这样的，目前是专署集群，我们希望从专署集群过渡到聚合各个IDC的RAM资源，比如说我们私有云机器去分容器、去分虚拟机，很多时候CPU是瓶颈，分完了内存有剩余，非结构化机器磁盘是瓶颈，磁盘或SSD被分完了但内存有空余，我们聚合整个RAM资源，让数据动态流动、去降低成本。

简单的跟大家交流这些，总结下来，我个人非常认同“内存是存储的未来”，特别是对结构化的、海量的、小的、需要快速访问的数据。从工程上来说，是“一件事，分布做，持续做”。

谢谢大家！

更多精彩内容，请关注直播专题2015中国大数据技术大会（BDTC），新浪微博ImapBox@邮箱云存储，订阅ImapBox大数据微信号。