电商的11.11大促，既是一场全民运动，也是顶级团队和技术的对决。

王晓钟，京东商城技术研发体系交易平台副总监，11.11大促，他介绍说基本的原则是保证主要的交易系统没有任何故障，这是多部门合作的结果。运维部门从网络层开始就准备了很多预案和容量规划，负责处理外部的流量，特别是恶意流量的甄别和处理。

交易系统瓶颈

谈到交易系统的瓶颈，他认为，随着系统数据和状态的变化，它不是一个固定的点。

以线上交易为例，依赖的逻辑分支特别多，包括用户信息、商品信息、价格计算、库存信息、虚拟资产使用情况等等，这些信息都来源于不同的服务，所以整个交易系统的逻辑特别复杂。

在前期准备中，京东内部进行了大量的压力测试，尝试找出可能的瓶颈点；在实际运行过程中，工程师密切监控，每个热点都有预案。处理的思路要么是提前准备很多组机器，分担流量，要么是临时开启一些细微的降级，增加一些缓存。

监控系统

京东的实时监控系统基本上都是通过日志分析来完成，包括软硬件多个维度，硬件包括CPU使用率、网络连接数等等；软件包括某个接口的响应时间、异常抛出的次数等等，当然监控系统也要做11.11备战，比如对于重要系统的数据隔离等等。

关于响应时间，目前瓶颈都在公网上，国内的互联网质量比较差。从服务器这边讲，每一百次调用中，最差的一次也只有15毫秒，但是到了公网上，根据测试，好的也是100多毫秒，差的甚至到1秒左右。

监控系统是京东自己开发的，所有的第三方的东西，它都造一个通用的轮子，京东以前还是一辆大卡车，用通用的轮子就可以了。目前这个业务量可以说已经是一辆跑车了，对轮胎的要求特别高，所以轮子都自己定制的，适合自己的业务、系统、软件、硬件，包括适合自己的人和管理。

云平台与容量规划

京东的底层系统其实分为两块，一块是内部的虚拟云，有不少系统是在用虚拟云系统；还有一部分，比如说交易，像这种交易也有一部分在用虚拟云，有一部分在用硬件，都是不一样的，看业务是否适合。因为云不适合所有的业务场景。比如说有状态的应用，对数据一致性要求高的，它就不太适合。有些像购物车的价格计算，完全没有状态，就适合。

云平台，第一，部署和管理上和以前相比要方便很多；第二，在故障处理上，有很多底层的可以自动切换的功能，合理的调配资源。

容量规划，主要依靠各个团队对于自己的未来业务的预测，京东的团队主要依靠自己的大数据系统。从大数据团队里获取业务增长数据的趋势。大家对这些趋势进行分析，可以合理的判断自己用户的增长量大致是多少。比如对用户团队来说，关注的是用户的登陆量和注册量，对交易团队来说，关心的是订单的增长量。商品团队关心的每天商品的更新量，还有商品的增长量，每个团队不一样。他们根据自己量的趋势来做自己的容量规划。

数据一致性

交易系统数据一致性，交易依赖的用户、商品、促销、库存这些接口，首先没办法做异步，只有同步的来做，而且如果做同步的话，分布式事务是很难绕过去的话题，对电商来说，简直是一个技术上的恶梦。

目前京东的做法很简单，提交的时候就做强一致性检查。提交完了，在强一致性检查的基础上，再做异步的一致性检查。某一单如果没有提交成功，那没有一致性问题。只要这一单成功了，系统肯定会保证数据一致性。

举个具体例子，交易一旦成功，用户余额如果扣了，那肯定就是扣了。不会存在交易成功，但余额实际上没扣的情况。还有优惠券也是一样的，必须是强一致性的。

线上测试

做线上的性能测试怎么不影响其他用户？举个例子，假设线上是两组系统，如果要做线上的性能压测，会把用户导到其中的一组上去，物理上和做压测的那一组隔绝。

因为对交易来说，现在交易已经做到分布式交易，各个组之间，包括数据都做了隔绝。如果一组压力过大出现问题，哪怕整组宕机的情况下，其他几组机群还是好的，快速的把入口流量一切换，保证用户体验。这一招就可以用在线上性能测试中。每次线上性能压测的时候，把用户导到一组隔绝的机器上，用户在上面跑。然后剩下的那几组就用各种工具进行压测，跑出的数据特别真实。

秒杀隔离

秒杀系统是今年从主交易系统中剥离出来，服务器和数据系统都是独立部署的，秒杀用的库存和商品信息都是单独推送到秒杀系统里，完全隔离。系统本身又做了很多针对秒杀的优化。

原文： InfoQ