京东分布式数据库如何应对大促活动_IDC国内资讯

在12月20日—22日的第十一届中国IDC产业年度大典上，京东资深架构师张成远对京东分布式数据库如何应对大促活动进行了详细的探讨。

张成远

京东资深架构师张成远

首先，我们一起来看看什么是分布式数据库，还有哪些场景要用到分布式数据库。分布式数据库是分布式的，它支持SQL，是多节点存储，这种存储方式可以分摊原本的单机数据库压力。

幻灯片4

其实，数据库在计算机领域发展的最早，也是发展比较成熟的分支。在七十年代，关系型理论开始提出，后面有很多的SQL类的产品，像My SQL，SQLSERVER。这些数据库用的都非常广泛，慢慢地随着整个互联网的发展，还有数据量的增多，有很多业务出现了一些状况，例如，单机的数据库扛不住业务量。因为数据量大了以后单机的压力也会很大，查询会降低；还有一个原因，Oracle等互联网公司都着眼于减少成本，会把这些数据库去掉，用免费的MySQL，这样做也需要相应的分布式数据库来解决存储的问题。

针对大促，不管是基础系统、还是业务系统都大同小异，有两个重要的应对步骤：一是前期的准备要非常的充足、完善；二是大促期间，要做很多预案准备，这样在大促开始以后，更多的时间是按照预案来进行处理。

幻灯片5

京东的解决方案是基于一套专门的分布式数据库的中间件，后面的存储会有很多的MySQL，因为中间件是金融MySQL，用户使用的是无感知的，就像使用MySQL一样来使用这套系统。

JManager则是管理路由信息的，如果每个路由信息都分开维护，代价会非常大，所以京东的路由信息是中心化管理，直接到这里提取路由信息即可。还有JTrasnfer系统，可能系统不确定数据量，后期想变成四台或者八台，就把原来的部分数据迁移到新的集群里，这样整个集群数据就会变大，相当于整个集群的规模会变大，进而能够支撑大的数据量，包括支撑的压力、支撑能力也会提升。然后还有JMonitor，一个系统正式线上使用时，除了核心的基本功能及性能满足以外，最重要的一点就是监控，特别是当支撑的系统是非常关键的系统时，如果有任何的异常情况无法发现，都有可能引起大问题。

幻灯片6

从去年到今年，京东去掉了大部分的Oracle，只剩余极少的几个，相应地把之前Oracle进到系统里的部分工作做了细微的调整，做成了让用户使用起来像普通的MySQL，但其实在里面用到了规则上的限制，要求它的SQL，像分布式缓存一样，确保用户的查询，尽量落在单库上。

一个事务里面有三条SQL，第一条SQL落在单库，第二条SQL落在单库，第三条SQL也落在单库上，这样整个事务是跨库的，但是每条SQL不跨库。京东有个运单系统，是非常重要的系统。刚到6月份，京东618大促还没到，就出现了整个系统卡死的问题，很多的SQL变得非常慢。经过全方位的排查，一个事务涉及到三个节点，其中两个节点都没有问题，但是第三个节点跟其它事务发生冲突，属于跨节点的冲突，产生连锁反应，造成大片死锁，致使情况变得非常严重。

找到原因之后，京东对SQL进行了相应地改写。正常意义上讲，去Oracle很困难，因为有很多的细节，系统一般都会有一段时间是双系的，写Oracle，同时写MySQL。这个过程中有任何的慢SQL都会被记录下来，应用所看到的慢SQL是这个层面，但是后面的链路非常长，对此，一般会把整个链路都非常详细地记录下来，这样就会很明确地定位问题，到底是网络的问题，还是数据库的问题。慢SQL出来之后，可能会出现这种情况，由于改的不好，造成大量的慢SQL涌现。这时候需要把这些慢SQL进行归类，然后对高频率出现的进行更改即可。

除此之外，还有定制化的路由策略，这是京东的特色之处。京东的分拣中心为了避免上海、北京等大城市分拣量大引发库的压力增大的问题，采用把量比较大的分拣中心制定在比较好的库上面，把一些数据量较小的分拣中心正常拆分。当小的分拣中心量变大时，再把变大的分拣中心挪出来，这样全部都在分布式数据库一层完成。

幻灯片7

刚才提到的整个链路很长，这与前端业务有关，在整个大促之前的链路是高可用的。一套系统上会分布两个JProxy，最多需要三个，通过域名连过来，Proxy后面的变化对业务无影响。JProxy会部署两个时，每个机房会部署两份，还有跨己方的灾备，因为有些机房可能会出现问题。在同机房部署的时候要考虑不部署到同一机架上，一个机架挂掉是有概率的。另外，MySQL跨机房部署，同机房还会有一份，这样部署是因为MySQL经常会出现主从切换，比如硬件问题，网线问题，需要经过切换，所以同机房会有一套从，另外一个机房还会有一套备。

高可用是一方面，还有全链路的压测和完善的监控报警。当核心功能不稳定的情况下，完善的监控报警系统就显得非常重要，比如最基本的存活监控。

幻灯片9