专访架构师：京东双11背后的NoSQL数据库与分布式存储内幕

大家好，我是主持人皮皮。每年的双11促销，都是对几大电商的软硬件平台服务能力的一次大考。京东每天的库房记录在十亿个数量级，商品图片总共有几十亿张。这些文件基本上都是KB 级别的，很明显关系型数据库不太擅长处理这些海量小文件，那么京东幕后的数据库和存储到底是什么呢？当用户京东上疯狂的进行流畅浏览、搜索、下单的背后，究竟是什么样的设备与架构才能支撑住如此庞大的流量？京东又是如何做到基于SSD的NoSQL优化？本期IT名人堂我们的访谈嘉宾是京东的分布式缓存与NoSQL数据库的研发负责人袁航先生（社区ID：hangyuancn），欢迎大家就自己感兴趣的问题积极提问或者留言发表看法，我们专家讲坐镇解答。



皮皮（Q1）： 袁总，您好！能否介绍下自己？

hangyuancn（A1）：1999年大学毕业后，我的家公司是深圳现代计算机有限公司; 我开始是接触Unix系统、小型机,使用C语言开发联通和移动的计费和营帐系统. 在此期间，由于工作需要和自己对底层软件的兴趣, 我采用C语言独立开发了交易中间件, 在黑龙江联通、甘肃联通、湖 南移动的营帐系统都得到了良好的应用. 后来，由于偶然的际遇, 同时出于对底层软件的热爱,我于 2001年受邀请, 加入了当时知名的国产中间件提供商-北京东方通科技;


在东方通作为设计师和核心开发人员, 我完成并发布了业界知名的企业级消息中间件 Tonglink/Q 6.0. 2004年开始接触并开始使用JAVA语言, 从事SOA的架构和研发工作, 并与2006年加入知名外企TIBCO的中国研发中心担任研发经理.


2011年进入互联网,电商行业 ,先后从业于兰亭集势, 当当, 京东. 在兰亭集势承担了业务消息系统的架构和研发工作；在当当承担了对外开放平台的架构工作. 目前担任京东分布式缓存与NoSQL数据库的研发负责人.



皮皮（Q2）：作为2015年数据库技术大会的演讲嘉宾，您能否和我们分享下您的演讲主题？


hangyuancn（A2）：在这里，我提前透露下我的演讲主题是《深入解读JIMDB—京东分布式缓存与高速NoSQL服务》，在演讲中，主要涉及JimDB从无到有, 从1.0得到3.0, 基于规模驱动和痛点驱动的研发历程; 重点包含监控和报警、故障检测和自动切换、迁移和扩容, 基于内存和SSD的2级存储等内容，干货十足，欢迎大家报名前来捧场！



皮皮（Q3）： 在NoSQL快速变革的世界里，DBA到底在扮演什么样的角色？面临哪些机遇与挑战？


hangyuancn（A3）：在NoSQL兴起的年代, 我并不认为DBA会变得无足轻重,只不过我我觉得DBA的职能会有所变化. 个人认为NoSQL时代，DBA关注的重心有所不同，会更加侧重于服务. 由于NoSQL发展初期的不成熟, 但发展极快, 这就要求DBA需要具有更强的学习和适应能力。


回顾京东NoSQL的发展历程，京东自主研发的NoSQL是一个从无到有、不断成熟、不段完善的过程。它并不是突然间就蹦出来的,也不是一拍脑袋决定要做就做的, 而是随着京东业务的迅猛发展, 比如双十一等高并发负载的重压下，我们在运维过程中会遇到这样那样的问题和痛点, 通过不断思考，在不断解决问题的过程中逐步发展起来的。


目前京东已经具备了很大规模的键值存储系统，JimDB实际上是一个规模驱动,痛点驱动的持续研发的产物, 在这个过程中为了支持数百个业务集群的7*24小时不间断运行, DBA是不可缺少的。当然随着JimDB不断成熟和发展, DBA的工作量会逐渐减轻。另外，除了键值存储, 我们还需要支持 JSON基于文档, 列式等多种NoSQL数据库, 这些都对DBA的学习和适应能力提出更高的挑战。


皮皮（Q4）： 京东每天的库房记录在十亿个数量级，商品图片总共有几十亿张。这些文件基本上都是KB 级别的，关系型数据库不太擅长处理这些海量小文件。京东早使用的内存键值存储是Redis，而现在转而使用了JimDB，您觉得为何会有这么大的转变？JimDB与Redis又能否兼容？


hangyuancn（A4）：事实上京东早使用的键值存储系统就是Redis，而JimdDB 1.0就是采用了Redis作为单机引擎,在此基础上，我们实现了监控和报警系统, 在客户端采用散列和一致性哈希技术来实现分布式;

但是随着京东业务规模的迅速发展, 我们在运维过程中遇到了一系列的问题和痛点: 节点故障靠人工恢复的时间是分支乃至小时级别,而我们需要秒级恢复, 以保证业务7*24小时不间断运行。当机器物理内存或者流量不足时, 我们需要进行在线数据迁移, 整个迁移必须平滑,不能出现业务中断的现象。当单节点空间太大,以及集群流量达到极限的情况下,我们就需要在线进行横向扩容, 扩容同样必须平滑进行，不能中断业务。


针对以上各种问题, 我们开发了JimDB 2.0，还有多种分布式组件: 基于分布式选举算法开发了哨兵服务, 以投票的方式判定节点死活,开发了故障自动检测和恢复系统,实现了秒级恢复.通过临时引入代理的方式实现了在线平滑数据迁移；通过引入元数据服务的方式, 实现了在线平滑横向扩容.


另外, 为了解决某些业务对空间有特别大的需求, 在JimDB2.0, 我们重写了 Redis单机引擎, 引入了2级存储, 在内存中存储热点数据， 冷数据被自动交换到磁盘，解决了内存空间有限的问题。

JimDB 2.0 虽然重写了单机引擎, 但是为了保持向前兼容, 网络协议仍然采用 Redis协议,与Redis客户端完全兼容, 因此客户端程序不需要做任何改变。


皮皮（Q5）： SSD没有传统磁盘的寻道时间和延迟时间，所以SSD可以提供非常高的随机读取能力，这是它的大优势，能不能谈谈基于SSD的NoSQL优化？


hangyuancn（A5）：Jimdb是基于SSD的键值存储，我们关心的是２个方面的指标：随机写和低延 迟．　这个方面我们做过很多探讨和研究，先后尝试过多个存储引 擎，　例如 Jimdb, leveldb等， 但是结果都不尽如人意; 后我们完全自主研发了自己的存储引擎cycledb,　达到了很好的效果，它可以在长时间连续的混合读写大压力下，提供令人满意且稳定的ops（每秒 操作数）和延迟.




皮皮（Q6）： 面对双十一大促，当用户京东上疯狂的进行流畅浏览、搜索、下单的背后，究竟是什么样的设备与架构才能支撑住如此庞大的流量？


hangyuancn（A6）：这个问题很重要，但覆盖面非常广，我仅从基础软件架构的层面简单说一下：在中间件方面面，京东自主研发基于SOA的服务治理平台JSF、分布式消息系统JMQ; 在存储领域，京东自主研发了分布式文件系统JFS, 分布式键值存储系统JimDB; 另外，　支持JSon 基于文档的NoSQL数据库和基于列存储支持宽表NoSQL数据库也列入了研发计划; 在弹性计算方面，京东有自己的Iaas平台JDOS和基于此平台的弹性调度系统COX. 正是基于这么多的基础软件的协同合作，才推动了京东业务量的持续不断增长，以及618和双11期间访问量的爆发性增长。




皮皮（Q7）：我们经常会遇到热点商品更新库存，秒杀，红包等场景。当同时大量更新数据库中的同一行时，就会产生大量的锁等待，数据库的性能就会急剧下降。京东又该如何做到并发控制的呢？


hangyuancn（A7）：对于这些情形，目前的处理方法基本不会直接访问数据库了，　看需求会使用缓存挡流量，　另外看情形综合利用服务治理平台和分布式消息系统解耦，传统的关系型数据库往往只作后归档用。