电商的 11.11 大促，既是一场全民运动，也是顶级团队和技术的对决。为了深入剖析 11.11 背后的技术力量，InfoQ 派出了多位编辑亲临各大电商的 11.11 指挥部现场，对一线的技术专家做了各个领域的专访。本篇新闻就是对京东商城技术研发体系交易平台副总监王晓钟的采访报道。
王晓钟介绍说，11.11 大促，基本的原则是保证主要的交易系统没有任何故障，这是多部门合作的结果。运维部门从网络层开始就准备了很多预案和容量规划，负责处理外部的流量，特别是恶意流量的甄别和处理。
交易系统瓶颈
谈到交易系统的瓶颈，他认为，随着系统数据和状态的变化，它不是一个固定的点。以线上交易为例，依赖的逻辑分支特别多，包括用户信息、商品信息、价格计算、库存信息、虚拟资产使用情况等等，这些信息都来源于不同的服务，所以整个交易系统的逻辑特别复杂。在前期准备中，京东内部进行了大量的压力测试，尝试找出可能的瓶颈点；在实际运行过程中，工程师密切监控，每个热点都有预案。处理的思路要么是提前准备很多组机器，分担流量，要么是临时开启一些细微的降级，增加一些缓存。
监控系统
京东的实时监控系统基本上都是通过日志分析来完成，包括软硬件多个维度，硬件包括 CPU 使用率、网络连接数等等；软件包括某个接口的响应时间、异常抛出的次数等等，当然监控系统也要做 11.11 备战，比如对于重要系统的数据隔离等等。关于响应时间，目前瓶颈都在公网上，国内的互联网质量比较差。从服务器这边讲，每一百次调用中，最差的一次也只有 15 毫秒，但是到了公网上，根据测试，好的也是 100 多毫秒，差的甚至到 1 秒左右。监控系统是京东自己开发的，所有的第三方的东西，它都造一个通用的轮子，京东以前还是一辆大卡车，用通用的轮子就可以了。目前这个业务量可以说已经是一辆跑车了，对轮胎的要求特别高，所以轮子都自己定制的，适合自己的业务、系统、软件、硬件，包括适合自己的人和管理。
云平台与容量规划
京东的底层系统其实分为两块，一块是内部的虚拟云，有不少系统是在用虚拟云系统；还有一部分，比如说交易，像这种交易也有一部分在用虚拟云，有一部分在用硬件，都是不一样的，看业务是否适合。因为云不适合所有的业务场景。比如说有状态的应用，对数据一致性要求高的，它就不太适合。有些像购物车的价格计算，完全没有状态，就适合。
云平台，第一，部署和管理上和以前相比要方便很多；第二，在故障处理上，有很多底层的可以自动切换的功能，合理的调配资源。
容量规划，主要依靠各个团队对于自己的未来业务的预测，京东的团队主要依靠自己的大数据系统。从大数据团队里获取业务增长数据的趋势。大家对这些趋势进行分析，可以合理的判断自己用户的增长量大致是多少。比如对用户团队来说，关注的是用户的登陆量和注册量，对交易团队来说，关心的是订单的增长量。商品团队关心的每天商品的更新量，还有商品的增长量，每个团队不一样。他们根据自己量的趋势来做自己的容量规划。
数据一致性
交易系统数据一致性，交易依赖的用户、商品、促销、库存这些接口，首先没办法做异步，只有同步的来做，而且如果做同步的话，分布式事务是很难绕过去的话题，对电商来说，简直是一个技术上的恶梦。目前京东的做法很简单，提交的时候就做强一致性检查。提交完了，在强一致性检查的基础上，再做异步的一致性检查。某一单如果没有提交成功，那没有一致性问题。只要这一单成功了，系统肯定会保证数据一致性。举个具体例子，交易一旦成功，用户余额如果扣了，那肯定就是扣了。不会存在交易成功，但余额实际上没扣的情况。还有优惠券也是一样的，必须是强一致性的。
线上测试
做线上的性能测试怎么不影响其他用户？举个例子，假设线上是两组系统，如果要做线上的性能压测，会把用户导到其中的一组上去。物理上和做压测的那一组隔绝。因为对交易来说，现在交易已经做到分布式交易，各个组之间，包括数据都做了隔绝。如果一组压力过大出现问题，哪怕整组宕机的情况下，其他几组机群还是好的，快速的把入口流量一切换，保证用户体验。这一招就可以用在线上性能测试中。每次线上性能压测的时候，把用户导到一组隔绝的机器上，用户在上面跑。然后剩下的那几组就用各种工具进行压测，跑出的数据特别真实。
秒杀隔离
秒杀系统是今年从主交易系统中剥离出来，服务器和数据系统都是独立部署的，秒杀用的库存和商品信息都是单独推送到秒杀系统里，完全隔离。系统本身又做了很多针对秒杀的优化。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论