电商们是怎么应对「双十一」这类节日中「高并发交易」的？

每一次618、双11购物狂欢，短时间的交易峰值给系统带来相当大的考验。
以今年的618数据来看，白条交易入口展示QPS千万级，营销规则匹配上亿级，支付成功率高达99.99%。支付体验更是丝般顺滑毫无卡顿……
废话不多说，下面就祭出白条应对大促的武功秘籍。

[h1]一、容量预估[/h1]备战618、双十一这样的大促活动，对容量的预估是一个重要的环节。通过以往的618及双11的数据分析，可以预估计当年618的量=2倍去年双11的量，白条也是按个规律来增速。

[h1]二、服务拆分[/h1]白条未拆分之前的部署环境，是把白条支付、白条退款、白条还款三大最重要的业务部署到同一个tomcat实例里。当有白条还款出现问题会直接影响到白条支付或白条退款，这点在系统上不是允许的。
为了更好的解决这个问题，我们将白条的核心业务做了拆分。白条支付只能部署白条支付的业务，不处理其它任何与白条支付无关的业务。白条还款，退款也是一样，只部署与白条还款、退款的业务。

对服务进行拆分的优点：

• 各业务系统互相不依赖
• 方便扩容及问题的排查
• 结构清晰，方便后续维护
• 功能单一，技术研发人员读起来轻松上手

[h1]三、白条性能调化参数[/h1]1、调整数据库连接池参数
数据库的连接池的参数设置的合理性，直接影响到应用实例和数据库交互。设置过小会造成连接不可用，设置过大浪费太多的资源，因此数据库连接池参数的重要性是不可忽视的。
白条使用的数据库为mysql数据库，采用分库分表储存方式，应用程序通过DBCP来访问数据库。其中核心的参数设置如下：

maxActive：链接池中最大连接数默认为8
maxIdle：链接池中最大空闲的连接数默认为8
minIdle：连接池中最少空闲的连接数默认为0
maxWait：当连接池资源耗尽时，调用者最大阻塞的时间，超时将跑出异常。单位毫秒数默认为-1，表示永不超时
minEvictableIdleTimeMillis：连接空闲的最小时间，达到此值后空闲连接将可能会被移除。负值(-1)表示不移除
timeBetweenEvictionRunsMillis：每隔多少秒运行一次空闲连接回收器，用于回收空闲的连接数

合理的连接池设置为：

• 评估数据库的最大连接数的设置，一般mysql单库的连接数不超过6000
• 评估应用实例的个数，单个实例设置的最大连接数*总的实例数据小于mysql 的总的连接数据
• maxIdle值与maxActive值应配置的接近
• 高负载系统的maxIdle值可以设置为与maxActive相同，让连接数量在minIdle与maxIdle间波动

2、调整tomcat参数

• Tomcat最大线程数（maxThreads） 设置1000
• Tomcat最大备用线程数（maxSpareThreads）设置750
• Tomcat最小备用线程数（minSpareThreads）设置50
• Tomcat 排队请求个数（acceptCount) ）设置为1000
• Tomcat URI编码为UTF-8；

3、调整JVM参数

• Xmx设置JVM最大可用内存为2G
• Xms设置JVM促使内存为2G,此值可与-Xmx相同，避免每次垃圾回收完成后JVM重新分配内存；
• XX:MaxPermSize设置持久代大小为256M
• XX:+UnlockExperimentalVMOptions设置解锁任何额外的隐藏参数
• XX:+HeapDumpOnOutOfMemoryError设置JVM在遇到OutOfMemoryError时拍摄一个“堆转储快照”
• XX:HeapDumpPath=$CATALINA_BASE/logs设置dump路径
• XX:ErrorFile=$CATALINA_BASE/logs/java_error_%p.log 设置错误文件日志

4、调整超时时间

• 数据库url超时配置(单位ms)

• ibatis配置超时时间(单位s)

• spring配置事务的超时时间(单位s)

超时时间在高并发系统中，是非常重要的参数。设置不合理可能会给系统带来极大的影响，比如请求处理不过来、造成服务的不可用，从而影响到正常的业务。

[h1]四、 技术保障[/h1]最早的白条架构以http接口为主，网络的性能消耗很大，而且接口性能抖动频繁。
京东自研的RPC框架完美的解决了这个问题，基于端到端直连，略过dns、vip等中间环节，内网通信，将网络的性能消耗降到最低。且支持同机房优先调用，服务故障自动切换，限流降级等功能，大大的提高了服务的稳定性。
另外，作为业务加速器的缓存相信大家也都不陌生。我们自研的redis集群稳定性、扩展性、容灾性都已经很完善，经过多次大促的考验，从未发现丢失数据的情况，完全可以当作内存数据库来使用。
除此之外，像应用解耦、异步消峰的消息队列，高可靠、高性能的数据库集群，基于hadoop、hbase的数据存储和处理平台，统一配置、日志、监控、部署等中间件系统，都为白条业务的快速发展提供了坚实、可靠的保障。

[h1]五、 架构优化[/h1]对于业务系统而言，每次的大促都是一个斗智斗勇、架构迭代升级的过程。下面我们来看下如何保证服务的持续可用。
应用层，基于RPC框架发布服务，多机房部署，异地多活，全局动态分配流量。当服务故障时，可按机房或应用或接口实现自动切换。
存储层，对于金融产品而言，数据库作为交易数据落地的介质，属于整个链路强依赖的部分，不容有失。白条的数据库模型采用DB+的模式，即mysql+分布式+nosql。数据散列分布在多库多表，且多个集群防灾互备。热点数据异步复制到nosql，对于618、双十一大促期间，性能的消耗主要来源于骤增的查询量，可适情况将高并发的查询量转移到nosql，保证交易数据正常落地



[h1]六、 性能测试[/h1]1、读服务性能测试
读服务的性能测试一般是根据业务在各级的展示入口，如：当月/日待还、白条总额度、白条的资产总页面等。
在大促期间，这些入口的量也是爆发式的增加，在性能测试这块，针对这些入口评估的压力值，一般为平常的10倍~20倍。
比如说PC端、APP的商品详情页面，在展示白条分期时，在618当天的调用量可达到15亿次的调用。
针对读服务的性能测试我们采用了如下处理办法：将线上服务拿一部分实例出来，通过JSF不同的别名，针对入口的单接口做压力测试，观察数据线上应用实例的情况，观察网络、磁盘、CPU、数据库的负载。

白条压力测试单台应用服务器的CPU图

白条压力测试单台应用服务器的TCP连接图

白条压力测试单台应用服务器的磁盘写入图

白条核心库的负载图

性能测试不达标解决办法：

• 服务器负载的问题，通过机器扩容或自动扩容解决，通过上下游的应用服务器来评估合理的机器数量
• 应用本身的问题、响应时间过长，通过走读代码、发现代码的瓶颈并进行优化，该增加缓存就增加缓存，设置合理的缓存失效时间 。如果是数据库的问题，增加索引或扩容数据库来分摊压力
• 网络问题，通过升级网络核心的设备来解决

2、写服务性能测试
写服务的性能测试是比较困难的。为什么这么说呢？原因比较简单，就是生产的所有数据都是真实的交易数据信息。为了解决这类问题，在考虑做写服务的性能测试时，特别申请了同线上同一机型的N台数据库服务器。

搭建写性能环境：

• 申请应用数据库服务器，同线上保持一致，包括数据容量、服务器的性能、网络环境
• 申请注册的性能测试账户信息
• 写应用的逻辑修改，通过测试账户数据信息，动态路由到新的测试数据库环境，与生产保持隔离
• 隔离MQ消息及上下游相关的数据

性能压力测试:

• 通过自动化压力测试平台，将测试账户录入
• 指定JSF的别名为压力测试的别名
• 以小部分的量进行并发压力测试，后续逐步放大，观察数据库、应用服务器、网络、TCP 连接等关键指标

3、混合场景性能测试
混合场景的性能测试就等同于线上高并发的流量进来一个模拟，通过此场景来发现在单独读性能测试和单独写性能测试的不足，从而找到系统在整个高并发环境里的缺陷，并安排后续的改进工作。

[h1]七、切换演练[/h1]为了保证服务的稳定性，切换演练是每年大促前必做的一件事情，切换演练具体包括许多方面，如数据库、VIP、JMQ、接口降级等。
1、数据库的切换演练
数据库采用主从模式，多机房异地部署，应用在配置数据库的连接时全部使用域名的方式进行访问。域名到VIP的这层，是动态可配置的，一般情况下不做修改。在数据库服务器出现问题（X机、硬件问题等），会自动切换到指定的从库VIP下，来保证服务的高质量。
2、vip的切换演练
白条在外网的通过https访问，就少不了对VIP的依赖，在商品详情页面，https的方式来访问白条的分期展示，默认是按正常的一个vip 对应不同的机房。当VIP发生问题时，手动调整VIP的切换来保障整体的服务不受影响。
3、jmq的切换演练
JMQ 是京东自主研发的消息平台，全公司的研发消息处理都走这框架。白条做为非常核心的业务，所有核心的JMQ 都是单独部署并支持通过topic 来进行切换，通过jmq演练，为业务系统提供最可靠的服务。
4、降级开关演练

白条在开发接口或应用时，针对接口必须提供可降级的配置信息，此配置数据信息直接接入白条单独部署的UCC的配置中心系统。
为了保证大促，针对系统接口的划分也是不一样的：一些0级系统不能降级，而一些展示类、流量类入口是可以降级的。当流量异常爆发时，通过开关的降级，保证最核心的业务不受到影响。

[h1]八、总结[/h1]随着用户体量的不断攀升，流量峰值的翻倍增长，以及人事的变动，相对于技术保障和架构优化，一套完善的备战机制甚至更加重要。
踩过无数坑，经过多次大促的沉淀，基本总结出来一套备战机制，下面跟大家一起分享讨论。
1、 系统压测
首先是压测准备，需要我们分析系统的性能瓶颈，评估流量的峰值。
其次是读压测，从单场景单机、单场景集群、复杂场景混合、跨网跨机房等多维度反复压测，直到达到预估值。
最后是写压测，主要是验证数据库集群的读写瓶颈。当然还需要注意很多细节，例如数据隔离、服务隔离、资源回收等。
2、 防刷限流
需要各个业务线按照各自的业务特点做不同的策略，例如公网可能考虑更多的是流量纬度的限流，而API服务更多是做用户纬度的规则处置。
3、 系统监控
业务应用、数据库存储、服务器等多纬度监控，及时发现解决问题。
4、 应急预案
对外做好降级准备，对内强依赖要做热备，按系统重要程度分级，大促前降级演练。宗旨就是：保交易。

本文作者：京东金融-技术研发部张栋芳&郭泽渊