【IT名人堂】专访高级架构师:京东双11背后的NoSQL数据库与分布式存储内幕

前端之家收集整理的这篇文章主要介绍了【IT名人堂】专访高级架构师:京东双11背后的NoSQL数据库与分布式存储内幕前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

大家好,欢迎做客第120期名人堂,我是主持人皮皮。每年的双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的键值存储,我们最关心的是2个方面的指标:随机写和低延 迟. 这个方面我们做过很多探讨和研究,先后尝试过多个存储引 擎, 例如 Jimdb,leveldb等, 但是结果都不尽如人意; 最后我们完全自主研发了自己的存储引擎cycledb, 达到了很好的效果,它可以在长时间连续的混合读写大压力下,提供令人满意且稳定的ops(每秒 操作数)和延迟.

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

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

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

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




作为国内数据库与大数据领域最大规模的技术盛宴,2015第六届中国数据库技术大会(DTCC)即将于2015年4月16日-18日在北京新云南皇冠假日酒店震撼登场。大会以“大数据技术交流和价值发现”为主题,云集了国内外顶尖专家,特别开设了Nosql专场,届时一淘及搜索事业部离线系统团队搜索研发专家雨田将发表主题为《HBase在阿里搜索的应用与扩展》的精彩演讲,京东高级架构师袁航将为大家讲解《京东内存存储技术演进》,360技术工程师王超将带来《Bada-构建主从/去中心混合架构的Nosql》干货分享。欢迎大家报名:http://dtcc.it168.com/

原文链接:https://www.f2er.com/nosql/203956.html

猜你在找的NoSQL相关文章