中国IDC圈12月26日报道,12月20-22日,第十一届中国IDC产业年度大典(IDCC2016)在北京国家会议中心隆重召开。本次大会由中国信息通信研究院、云计算发展与政策论坛、数据中心联盟指导,中国IDC产业年度大典组委会主办,中国IDC圈承办,并受到诸多媒体的大力支持。

中国IDC产业年度大典作为国内云计算和数据中心领域规模最大、最具影响力的标志性盛会,之前已成功举办过十届,在本届大会无论是规格还是规模都"更上一层楼",引来现场人员爆满,影响力全面覆盖数据中心、互联网、云计算、大数据等多个领域。

会上,京东资深架构师  张成远出席本次大会并为当天的IDC上市企业大会做 《京东分布式数据库如何应对大促活动》主题演讲。

张成远

京东资深架构师  张成远

以下是演讲实录:

张成远:大家好,我今天分享一下京东分布式数据库如何应对大促活动。我叫张成远,是京东架构师,毕业于东北大学,研究的是分布式数据库方向,在京东一直做分布式数据库相关的事情,是《MariaDB原理与实现》的作者。在京东负责分布式数据库相关的架构设计以及大规模的落地推广,我个人比较擅长高性能服务器开发,以及大型分布式系统架构设计。

我觉得针对大促来说,不管是基础系统、业务系统都大同小异,它最主要的只有两个步骤,就是前期的准备要非常的充足、完善,大促期间,因为前期做了很充足的准备,有很多的预案,到大促期间只需要按照预案来处理就行了。也就是说正常情况下,所有忙碌的工作都是在大促开始之前,等到大促开始以后,更多的是淡定地处理线上的一些情况。

讲一下什么是分布式数据库,还有哪些场景要用到分布式数据库。从名字上就可以看出来,分布式数据库首先是分布式的,还是支持SQL,是多节点存储的,这样可以分摊原本的单机数据库的压力。数据库的发展,在计算机领域发展中非常早,也是发展比较成熟的分支。在七十年代,关系型理论开始提出,后面有很多的SQL类的产品,像My SQL,SQL SERVER,这些数据库用的非常的广泛,慢慢的随着整个互联网的发展,还有现在的数据越来越多,有很多业务就会慢慢出现一些情况。比如说单机的数据库不一定能扛的住业务量,因为数据量大了以后单机的压力也会很大,这样查询也会有所降低。在互联网领域,还有一个原因,Oracle等互联网公司都想着怎么节省怎么来,会把这些数据库去掉,用免费的MySQL来扛,这样做也需要相应的分布式数据库来解决这些存储的问题。

直接讲一下京东的解决方案。我们有一套专门的分布式数据库的中间件,我们后面的存储会有很多的MySQL,因为中间件是金融MySQL,用户在使用的是无感知的,他就像使用MySQL一样的来使用这套系统。他的SQL正常写,数据正常过来。实现会制定路由的规则,我们会把数据落到后面的相应节点上去。属于查询的话,他的SQL正常过来,我们会把SQL解析过来,如果只是查询某几条记录,我们会把SQL解析成一个执行计划。

JManager就是管理路由信息的,如果每个路由信息都分开维护代价会非常大,所以我们的路由信息是中心化管理,所有的都到这里来取路由信息就可以了。还有JTrasnfer系统,可能我的系统不确定我的数据量,我后期想变成四台或者八台,我们就把原来的那部分数据迁移到新的集群里面,这样的话整个集群数据会变大,相当于整个集群的规模会变大,能够支撑的数据量,包括支撑的压力、支撑能力会提升。然后还有JMonitor,因为一个系统在线上真正去用的时候,它除了核心的基本功能满足以外、性能满足以外,非常重要的一点就是监控,尤其是当你支撑的系统是非常关键的系统,如果有任何的异常情况没办法发现,都有可能引起非常大的问题。

我们这套系统从去年到今年,公司全部的Oracle都去掉了,现在剩下业务的极少数的几个,去掉Oracle进到这里面有一些工作需要调整,我们做成了让用户使用的感觉像一个普通的MySQL,但是它还是有一些使用规则上的限制,或者说一些规则,我们会要求它的SQL,因为会插很多的片,分布式缓存也一样,你要确保你的查询,尽量地落在单库上我们会要求SQL尽量的改写,落在单库上。

订单的ID,要ID等于多少,这套SQL一定落在某一个库上,因为它的ID是唯一的。像这种SQL都会尽量的改写,避免跨库的事务,这个事情比较有意思,如果你跨库,基于MySQL去做一个分布式事务的支持是比较困难的,大家如果感兴趣可以去搜一下我之前有做的一个分享。业务方使用这个的时候,他能够让他一个事务里面的SQL都落到一个单库上面去,但是它也会出现一种很玩的情况,他的每条SQL都落在一个单库上,但是整个事务是跨节点的,比如说一个事务里面有三条SQL,第一条SQL落在单库的,第二条SQL也落在单库的,第三条SQL也落在单库上,这样整个事务是跨库的,但是每条SQL不跨库。公司有个运单系统,也是非常重要的系统,我们在线上跑了两个月都非常的平稳,还没有到618,因为京东618有大促,刚到6月份,大促的量还没过来的时候,出现了一个问题,就是整个系统卡死了,很多的SQL非常慢,我们排查原因,一个事务涉及到三个节点,其中两个节点都是没关系的,但是第三个节点跟另外的事务冲突了,另外的冲突也是跨节点,这样就会连锁反应,就会一大片都是死锁,这个事情就会非常的严重。我们找到原因,要求业务方把这个改掉。他说我每条SQL都是落在单库上的,我不能确定我的事务怎么就跨节点,我们这边会提供,如果你的SQL是跨库,我们一定是直接记录,如果每条SQL都不跨库,都落在单点上,但是如果整个事务跨多个节点,我们也会记录,你就照着我们记录的改就好了,因为整个系统在那里,你直接看你的系统,你这个业务,现在跨库的事务有哪些可以改。

以正常来说,去Oracle这个事情是蛮困难的,因为有很多的细节,我们的系统一般都会有一段时间是双系的,同时写Oracle,同时写MySQL这套。这个过程中有任何的慢SQL我们都会记录下来,应用所看到的慢SQL是这个层面,但是后面的链路非常的长,我们记录慢SQL,会把整个链路都会非常详细地记录下来,这样就会很明确地定位问题,比如说是网络的问题,还是数据库的问题。慢SQL出来以后,有些因为刚切过来的时候就会出现那种情况,它可能改的不是特别好,就会出现大量的慢SQL,这个时候系统的开发人员就会说,那你告诉我优先该改哪个SQL,大量的慢SQL有些是相同的,可能是同一类型的,我们会把这个SQL全部归类,告诉你哪条慢SQL出现了多少次,在多长时间以内出现多少次,他直接挑最高频率改,慢慢改就可以。

还有定制化的路由策略,也有比较有京东特色的,像我们的分检中心,它是全国的分检中心,它的量是不一样的,上海的分检中心和北京的分检中心量就会比较的,如果按照分检中心普通的拆分来说就会出现一种情况,就是说你可能会跟大的分检中心都落到同样的库上面去,这样的话,那个库的压力就会非常大,我们怎么来避免这个问题呢?因为哪些分检中心量比较大或者比较小我们都是知道的,我们就会把量比较大的分检中心制定到比较好的库上面,把一些数据量比较小的分检中心正常的拆分就可以了。当小的分检中心量变大,再把变大的分检中心再挪出来,这样的话业务系统就不需要关心这些东西了,全部都在分布式数据库这一层搞定。

因为刚才也看到整个链路很长,还有与前端业务相关。在整个大促之前整个链路是高可用的,如果高可用都保证不了这个事情就很麻烦。先讲一下高可用,高可用就是你的系统挂了怎么办?业务的应用实例会部署多份,很多应用部署的实例数一步就布上百个或者几百个。我们一套系统会布两个JProxy,最多需要三个。通过域名连过来,Proxy后面的变化对业务没有影响,比如说正常的系统之间连MySQL主从,它后面发生切换,如果你的应用非常重要,你会想快速地让链接生效,连到新的主上面去,这样业务是要重启的,在这里是不需要的。JProxy会部署两个,每个机房会部署两份,还有跨己方的灾备,因为有些机房会因为一些原因出问题了。在同机房部署的时候要考虑不要部署到同一个机架上面,一个机架挂掉还是有概率的。另外就是MySQL跨机房部署,同机房还会有一份,这样的话,因为MySQL经常会出现主从切换,比如硬件出了问题,网线出了问题,需要经过切换,所以同机房会有一套从,另外一个机房还会有一套备。

除了高可用以外,还有很多的事情,比如说大促之前我们一般会有全链路的压测,这样会找到到底哪个环节是最薄弱的,需要扩充相应的资源。

还有非常完善的监控报警,监控报警这个事情非常的重要,因为当你的系统,尤其是你的核心功能不稳定的情况下,如果没有完善的报警,两眼一抹黑的状态,出了问题也不知道是什么,也没办法拿线上的系统做调试,所以一定要有一个非常完善的监控报警系统,比如最基本的存活监控。像数据需要有慢SQL的监控,因为慢SQL很有可能已经有问题,我们经常会有一些系统出现慢SQL,然后我们就会马上去排查。其实有些很简单的事情不太容易避免,而且发生的概率是比较高的,比如说它的网络包重传,或者说丢包了,它可能只是网线松掉了,或者网卡有问题了,类似这种硬件的事情,这些都是征兆,你不能等到已经彻底挂掉了再去处理,所以除了存活监控,在这之前还要做更加精细的监控。还有连接数监控报警,你每次查询比较慢,它就会变成大量的连接。还有一种情况业务误连了,这样的话连接数也会很高,针对这个我们会权限控制。还有CPU/内存/网卡/磁盘/网络质量等基础系统监控,比如这套MySQL有大量的数据,做大量的查询,然后大量的解包,CPU就会大量的往上飙。内存,如果说你的一条查询过来以后,MySQL那边的数据量非常大过来,同时SQL连到中间件的服务商,中间件有一千多个分库,每个分库都非常大,任其数据往中间件这儿发会产生非常大问题,数据量非常大,前面出去只有一条链接,自身的内存就爆掉了,我们会有内存保护,到一定程度,其他的压在TCP里,这样保证整个内存。其实网络质量非常关键,有问题的话可以及时处理。数据分布情况,我的数据是否均匀,是否会出现某个分区数据量非常大。

线上异常如何应对。我的感觉是,充分的预案和演练。你能想到的异常一定会遇到的,在一个分布式系统里面,你的节点越多,出错的概率就越大,任何一个节点都有挂掉的几率,就算不挂任何一个节点,网络都有可能出问题,如果网络没出问题,它也会出问题。整个分布式系统是说任意一个节点出问题,都需要保证系统是否在可控范围之内,如果不能保证,你的系统在线上跑都会非常悲催,可能没办法百分之一百能想到,但是你能想到的异常它基本上都会遇到。我们会针对所有的能想到的异常做好相应的预案,大促之前会有很多的预案演练,比如说其中某个节点应该做什么处理,比如网线拔掉会有什么影响,我可以在多快的时间内应对这些东西。真正到大促,很少出现一个新的问题,需要临时解决,这样往往会出问题,绝大多数情况下所有的异常都准备好,在大促的时候如果遇到问题,我们只是按照预案进行操作就可以了,避免思考的就尽量避免,不是说不去思考,而是说真正所有的准备工作都应该在大促之前准备好,大大促出问题都属于机械化的应对就可以了。

但实际情况未必那么完美,会有极少数的情况需要多想一下怎么处理,可能是预案不一定完全的覆盖的到,但是覆盖率来说还是非常的高。

大促中基础系统团队的状态,我想表达的就是真正大促的时候坐在那里看看监控,看看报警就好了,出问题就照着预案来处理就好,基本上是这样子,前提是整个团队是比较成熟的,还有整个公司配套的系统都非常成熟的话是这样子。对于一些在发展中的团队,他遇到的这种情况,他未必能够那么悠闲,因为有些东西准备很难那么充分,但京东这么多年过来,现在相对来说,不管是系统还是处理方案、团队都变得更加的成熟。

关注中国IDC圈官方微信:idc-quan或微信号:821496803 我们将定期推送IDC产业最新资讯

查看心情排行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党