【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014，关注关注中国数据库技术大会公众号）现场演讲嘉宾刘海锋老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼

　　讲师简介

▲刘海锋

　　京东首席架构师，曾带领团队先后建设分布式存储、中间件、CDN、弹性计算云等技术体系，目前负责商城系统架构、深度学习与人工智能等新技术方向。

　　正文

　　各位朋友，大家好!我今天分享的主题是《大规模内存数据库：从NoSQL到NewSQL》。

　　Jim Gray曾说过：Memory is the new disk，内存是新的磁盘。在过去几年我亲身体验到了整个趋势的变化，因为在任何的互联网公司，特别是电商行业，会大规模的使用缓存，但缓存演变到今天已经不是简单的缓存了，实际上它已经成为了数据访问的中心。

　　京东网站上主要的动态内容都是由今天要跟大家分享的系统——JIMDB支持的，这个系统是从14年初开始建设。分为如下三个片段为大家介绍JIMDB整个系统的演进过程：

　　自2014年初开始做JIMDB，只想把公司各个团队自行维护的缓存做成更健壮的分布式系统，更好地服务业务。整个系统的架构比较松散，存储结点下的每个server都是一个redis定制版本。各个外围模块相对独立但互相配合：有负责监控的，下发配置，扩容控制，分布式故障监测，主从切换等等，应用通过Java客户端或者Go代理接入。逐渐演进成为一个比较完善的基础平台。

　　简单介绍两个主要的技术点。首先，如何精确检测故障以及进行快速切换以保障可用性，这是最基础也是最重要的。每个机房部署自己的Failure Detector，每一套故障检测器都分布在一个机房不同的机架位置上，通过分布式做比较精确的故障检测，检测到故障后通知另外一个模块，它会发起Failover到配置中心修改配置，进而这个配置会推送到Java客户端或GO代理，改变访问路由。

　　另外一个关键的技术问题是动态扩容，即随着容量增长自动扩充资源。

　　基于部分复制(partial replication)技术来实现动态扩容。从模型来说是集群分成bucket，以bucket而不是shard作为复制单元，每个bucket和shard之间有一个归属关系，可以通过bucket复制进行灵活调整，实现在线重新分片与数据均衡。

　　对分布式系统特别是大规模的平台化来说，监控体系至关重要。一方面要为业务服务，另一方面为系统建设者所用。JIMDB经过两年多的发展已经形成了非常完善的监控体系。

　　14年到15年初，JIMDB用一年时间演变成为一个高质量的分布式系统服务。每天有无数的业务上线创建集群，集群的生命周期接受还要回收，所以运维工作比较辛苦。因此，15年初到16年初，团队设计开发了JIMDB第二版，主要是实现平台的全自动化维护：自助申请接入，自动分配资源，基于容器自动部署。事情说起来简单，但花了很多心思去建设。

　　接下来跟大家分享一下内存数据库可以给公司带来什么收益，就是较好的性能。

　　举个简单的例子，去年双十一当天的TPS超过两百万，百分之九十九的延迟都低于两毫秒。一方面让终端用户的体验更好，另一方面更主要的是业务产品开发团队可以更多的聚焦在业务功能的满足上，而不是性能调优上。

　　基于内存做在线数据的存储有一个弊端——成本。而成本是一个相对的概念。在07年，08年左右，我们比较常用的服务器内存是4G，而今天线上采购的内存一般是256G加万兆网。照这个规律发展下去，估计明年年底很多公司都会采购标配1TB内存的服务器。内存的增长在某种程度上让成本问题变得不那么重要。此外，我们不断进行底层技术优化来降低内存碎片率。

　　经过两年的发展，JIMDB现在可以认为做成了一套企业级NoSQL服务。完全兼容Redis数据类型，分布在几个机房数千台机器几万个docker实例，普遍使用万兆网络，支撑京东几乎所有在线业务。

　　今年第一季度我们梳理了线上应用情况，发现JIMDB绝大多数都应用于缓存场景，但不是局部热点缓存，通常是全量数据缓存。如上图为例，JIMDB后面是MySQL集群，两个系统都放全量数据。对公司的应用开发团队来说，工作仍然比较复杂，一方面要维护两个系统之间的数据一致性，另一方面MySQL的横向分片扩容很麻烦。

　　缓存提升数据访问性能，但增加了开发复杂性。公司一般把MySQL等传统关系型数据库作为持久存储，其实很少用到关系型数据库的高级特性。而且，MySQL存储可靠性还不够高，在主实例突然断电的情况下，数据依然可能发生丢失现象。因此从应用开发和系统运维角度来看，整个架构一定会发生变革。

　　JIMDB第三代，从Redis兼容的NoSQL到MySQL兼容的NewSQL，目标是使得在线数据访问变得更加简洁。系统两层架构，前面是无状态的兼容版SQL协议的API结点，后面存储数据的机器形成一个新型分布式数据结构 - 在内存中分布式B-Trie,平衡字典树,简称为MBT。

　　对比之前版本，其存储引擎、复制协议、分片策略都进行了重新的设计与实现。特别是状态机复制和按范围分片使得整个工程复杂度增加了。

　　事务方面，我们并不追求技术上的绝对完美。而是针对电商场景，适度放松事务语义，能够满足关键业务场景即可。实现理论上的可串行化，性能开销很大，实现很复杂，业务也并不需要。

　　就给大家简单分享这些，很多技术点并没有过多解读，总结起来就一个想法：一件事分步做，持续做，坚持三年就会很不一样。另外我坚信内存是存储的未来。

　　我的分享到此结束，谢谢大家!