【IT168 评论】眼看着一年一度的“11.11”电商节购物狂欢季即将来临，各大电商平台也纷纷摩拳擦掌准备大干一场。但是网友消费热情的上涨不免对电商平台后端的数据中心提出更高的要求，许多消费者或许还记得几年前由于系统原因造成的卡单、丢单等事情，大大影响了用户体验。为此，近年来各家电商也都提前准备应对策略，积极的寻求瞬间大流量的解决办法。日前，京东召开11.11技术备战大会，详细介绍了京东如何应对即将到来的“11.11”电商节流量高峰，并特别提到了已经成功通过验收并投入使用的“多中心交易项目”(一期)。

　　建设“多中心”咋就这么难?

　　许多人都有着这样的经历——节假日去大超市购物最烦心的就是结账台前漫长的排队与等待。为什么不能多开几个收银柜台?或者不同类别的商品分别结帐?我相信许多人在苦苦等待中都会有这样的想法。同样，对于网上购物来说，虽然不存在实际情况中的等待问题，但是建设多个中心的确能够起到缓解流量，提升效率的作用。更重要的是，不久前某电商的“光纤事件”给整个行业都敲起了警钟，实现异地容灾，保障数据可靠性已经刻不容缓。

　　正是基于效率、安全与冗余等多角度的考虑，京东集团正式提出了“多中心交易项目”，旨在通过优化交易系统的技术架构，提高系统的扩展能力和容灾水平，支撑业务的高速发展。正如我们分析的那样，虽然增加多中心可以切实解决问题，但也随之带来了后端数据层面的诸多问题。比如那个被众人诟病的12306网站，之所以春运期间买火车票难上加难，之所以明明看着有票登录之后却卖光了，其根本原因就是没能够解决数据一致性的问题，由此才引起网友们一遍遍的刷新，甚至许多网站也研发各种“刷票”软件推波助澜，最终引起12306网站瘫痪。

　　由此可见，多中心交易本质上是一个更大的分布式系统，交易流程中依赖和产生的数据和服务有不同的特点，必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。其中，数据一致性是电商网站需要面临的首要问题，越是流量增大的时候越要保证数据更新的即时性和准确性。在多中心之间需要同步卖家数据和商品数据，如果同步的延时太长，买家、卖家都不可接受。比如，卖家改了价格或库存，用户不能过很久才看到。同样，数据正确性也是很大的挑战，卖掉的商品能够及时减少，退货的商品能够及时增加。这都时刻考验着后端系统和数据库平台的健壮性。

　　除了数据一致性之外，如何保证路由规则的一致性也是关键性的问题。从技术角度来说，要保障单一用户从登录到访问服务、到访问数据库，全链路的路由规则都是完全一致的。如果路由错误，看到的数据不正确，也会影响到最终用户的体验。

　　如何组建高效、便捷、安全的“多中心”

　　文章的最初我们提到，“多中心交易项目”(一期)已经成功通过验收并投入使用，也就是说京东已经在11.11之前解决了数据一致性与路由规则一致性的问题。那么它是如何解决这两大难题的?目前京东的“多中心”架构特点是什么呢?

　　按照规划，京东的多中心交易系统架构，包括若干个主中心和多个分中心，主中心与分中心之间通过数据总线交换数据。从数据流向的角度来说，主数据(商品数据、商家数据、用户数据等)的流向从主中心通过数据总线实时同步到分中心，分中心只读;交易数据(订单数据)的流向从分中心实时同步到主中心;故障时，分中心转移到主中心。换句话说，买家访问京东网站下单时，会按照地域优先分流到附近的交易中心，用户的下单操作是在分中心完成，相当于在超市独立的收银台完成;而主中心则负责把控用户看到的商品数据等信息是否准确，负责校验数据一致性。这样一来，两部分中心各司其职，有效的实现了流量的分配，化解了流量高峰问题。

　　以新注册的用户为例，在注册的时候系统会根据用户的IP定位其位置，分配一个机房标识。登录时将机房标识写入cookie供PC端web应用获取、更新对应机房的集中式session缓存，同时在用户基础读服务中提供用户机房标识供其他内部服务调用(比如移动的网关服务)。而对于之前的老用户来说，则是在切流量上线的过程中逐步更新这个标识，达到统一管理的目的。

　　从同城双机房的分布转变为异地多机房的分布，给数据同步带来了新的挑战，因此如何设计数据总线也是项目能否实现的关键因素。京东的多中心交易系统通过数据总线Jingobus进行快速数据交换，同步性能是mysql的3倍以上，而且可用性高，架构灵活。其中，全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题，实现了高性能、低延时、健壮的数据同步机制。

　　如图所示，数据总线主要分Relay、Snapshot和Replicator三部分构成，其中Relay从来源数据库抽取事务日志，并对Replicator提供日志订阅服务，角色上相当于Mysql Slave IO Thread。Snapshot从Relay订阅所有事务日志，写入持久存储作为快照，同时向Replicator提供批量日志订阅服务，角色上相当于Mysql Slave Relay Log。Replicator：事务日志的消费端，从Relay或Snapshot拉取事务日志将事务日志按配置的一致性应用到目标数据库，角色上相当于Mysql Slave SQL Thread。

　　正常情况下，Replicator直接连接Relay，消费Relay内存队列中的事务日志。但有些情况下，因为网络抖动、目标库的负载过高等因素，可能导致Replicator相对Relay落后很多。另外，当新的消费端加入同一数据源的订阅者时，新消费端有冷启动的问题。为了避免重新从数据源做全量快照，Snapshot作为Relay的一个特殊消费端，通过一种高吞吐的消费方式，从Relay源源不断的消费在线事务日志，通过对事务日志的有效处理，最终保存了数据源的一份一致快照(Consistent Snapshot)，即包括了数据源库表中每一行的最新状态的快照，同时保留了一段比Relay buffer更旧的事务日志(Log Store)。由此看来，数据总线作为一个数据层的通用CDC组件，对于多中心交易项目以及异步复制场景提供了整体解决方案，奠定了项目的核心内容。

　　京东多中心交易系统的出现，一方面提升全国京东用户的访问速度，实现就近访问，另一方面也增强了京东的扩容能力、容灾备份能力，为京东11.11电商节带来更高的运营保障与更好用户体验。据京东集团高级副总裁、研发体系负责人张晨透露，目前京东相关团队的11.11电商节促销应急方案将近有1500个,每个团队的应急演练接近150场，还有两次各部门联合演练。如今，第一期的多中心交易项目已经正式投入使用，未来的二期项目将在2016年618促销之前完成，而最终的项目竣工将在2016年10月。