支付系统-1.3.2版本部署性能测试

1.3.2版本的更新与改动：

1.重新设计了数据库，将所有的id字段由原来的varchar类型的uuid改为了bigint型的数字，将account_no、point_account_no等也由varchar改为了bigint。java应用端也根据字段的改变做了调整，有redis实现全局id。

2.service-user模块中为public RpUserInfo getDataByMerchentNo(Long merchantNo) 与public RpUserPayConfig getByPayKey(String payKey)与public RpPayWay getByPayWayTypeCode(String payProductCode, String payWayCode, String payTypeCode)方法添加了redis支持，对于同样请求的数据，第二次开始讲无需去数据库查询，而是直接从redis中读取

3.app-queue中加入了由redis实现了全局锁，对于同一账户的任务，将先获取该账户对应的锁才能继续向下执行banktask，将原本数据库端的锁竞争压力前移。减小了数据库端的压力。

4.基础账户数增加到了2000个

1.3.2第一次测试：

本次测试的用的拓扑架构与1.3.1相同，但是遇到了网络瓶颈，具体为：

系统的qps一直稳定在140左右无法继续上升，所有数据库服务器与应用程序服务器的cpu指标都正常，甚至是维持在一个较低的水平。但是系统的订单产生的速度与完成的速度一直处于一个平衡的状态，即使加大请求的密度，订单的产生速度依然也维持在140-200笔/秒左右，初步估计是网络的原因。

以下是测试状态下，订单全速生成时的一条订单的执行流程对应的log，分析过后可以找到系统的瓶颈

[INFO ][20180428 10:52:34,619][RpTradePaymentManagerServiceImpl:144] 接收到订单数据2018042810523376737
[INFO ][20180428 10:52:34,635][RpTradePaymentManagerServiceImpl:149] ===>验证RpUserPayConfig有效性结束，订单号:2018042810523376737
[INFO ][20180428 10:52:34,689][RpTradePaymentManagerServiceImpl:159] ===>查询payWay结束，订单号:2018042810523376737
[INFO ][20180428 10:52:34,696][RpTradePaymentManagerServiceImpl:172] ===>查询RpUserInfo结束，订单号:2018042810523376737
[INFO ][20180428 10:52:34,703][RpTradePaymentManagerServiceImpl:175] ===>查询RpTradePaymentOrder是否存在结束，订单号:2018042810523376737
[INFO ][20180428 10:52:34,713][RpTradePaymentManagerServiceImpl:191] ===>插入RpTradePaymentOrder结束，订单号:2018042810523376737

[INFO ][20180428 10:53:16,136][RpTradePaymentManagerServiceImpl:207] 接收到支付结果{result_code=SUCCESS, payKey=d2cbf1429cdb4553966e7361bd9da17c, time_end=20180428105234, messageId=f7f9e48810af4d5eaf287088f57e4725, out_trade_no=2018042810523376737, payWayCode=TEST_PAY_HTTP_CLIENT, transaction_id=20180428105234}
[INFO ][20180428 10:53:16,137][RpTradePaymentManagerServiceImpl:211] ------[接收到要处理的订单2018042810523376737]--------[开始处理时间2018-04-28 10:53:16 137]------
[INFO ][20180428 10:53:16,146][RpTradePaymentManagerServiceImpl:283] ==>开始处理支付成功的订单结果2018042810523376737
[INFO ][20180428 10:53:16,155][RpTradePaymentManagerServiceImpl:286] ==>保存消息数据2018042810523376737
[INFO ][20180428 10:53:16,165][RpTradePaymentManagerBizImpl:61] ------completeSuccessOrder[订单2018042810523376737完成支付TRYING阶段开始时间2018-04-28 10:53:16 165]------
[INFO ][20180428 10:53:16,178][RpTradePaymentManagerBizImpl:71] ==>Record update完成[订单2018042810523376737]
[INFO ][20180428 10:53:16,200][RpTradePaymentManagerBizImpl:81] ==>修改订单账户金额[订单2018042810523376737]
[INFO ][20180428 10:53:16,367][RpTradePaymentManagerBizImpl:83] ==>修改订单账户金额完成[订单2018042810523376737]
[INFO ][20180428 10:53:16,367][RpTradePaymentManagerBizImpl:86] ==>修改账户积分开始[订单2018042810523376737]
[INFO ][20180428 10:53:16,417][RpTradePaymentManagerBizImpl:89] ------completeSuccessOrder[订单2018042810523376737完成支付TRYING阶段结束时间2018-04-28 10:53:16 417]------
[INFO ][20180428 10:53:16,422][RpTradePaymentManagerBizImpl:95] ------confirmCompleteSuccessOrder[订单2018042810523376737完成支付CONFIRMING阶段开始时间2018-04-28 10:53:16 422]------
[INFO ][20180428 10:53:16,450][RpTradePaymentManagerBizImpl:111] ------confirmCompleteSuccessOrder[订单2018042810523376737完成支付CONFIRMING阶段结束时间2018-04-28 10:53:16 450]------
[INFO ][20180428 10:53:17,616][RpTradePaymentManagerServiceImpl:298] ==>发消息前：2018042810523376737

该条订单生成时可以确定redis中已经保存了该订单产生所需的RpUserPayConfig与payWay与RpUserInfo，而分析log可得这几步在运行时消耗了大量的时间，以验证RpUserPayConfig有效性为例，全速测试时花了0.016秒，而在平时测试时，该步骤只需0.002秒左右，所以我怀疑是网络的原因。

为验证我的猜想，我在全速测试时，将服务器互相ping，得到的结果是部分服务器间的延迟会上升到10ms左右，甚至出现几十ms的情况（具体的图片就不放了，我也没截图）。后经过我对机房的查看，我所用的服务器分布在不同的机架上，导致其实我的众多的服务器是连接在多个千兆交换机上的。以下是机房10.8.59.0网段的的大致拓扑图：

我发现正在使用的服务器分布于3个机架（交换机），而作为流量重点的组成openstack的六台服务器分布于两个机架（两个交换机下），也就是说存在一次service的调用需要跨越3个交换机，网络的瓶颈应该在这里。订单全速测试时，跨交换机的服务器（以及虚拟机）间延时较高，而同一交换机下的服务器（以及虚拟机）延时并未有多大变化。

解决的方案：我将六台组成openstack的服务器放到了同一个机架上，使用同一个交换机，确保mycat及以上应用程序的数据都只在一个交换机内流转，这也是产生网络流量最多的部分。数据库集群，由于涉及到的服务器较多，无法都放在同一个交换机下，还将分布于多个交换机下，同时这里产生的网络流量也较小，应该不会发生网络瓶颈的问题

警示与提醒：

1.对于需要消耗大量网络流量完成通信的应用，最好还是放在同一交换机下，尽量做到高流量应用间不跨多个交换机进行通信。

2.检查网络情况，网络质量由多个组件结合而成，能接触到的最多的是交换机、网卡、网线，其中网线最容易被忽略，我在机房查看时发现有两台服务器居然使用的是10M的网线（现已更换为千兆网线），此时网线将成为网络的瓶颈，即使交换机与端口是千兆的，网络依然无法达标。

3.一般服务器（电脑）都会有多个网卡，可以使用多个网卡对网络流量进行分流，例如本系统中的gen8与gen9有四个千兆网卡（插口），可以将所有服务器的1号插口用一个交换机连接新建一个网段用于java应用间的数据流通，将所有2号插口用一个交换机连接新建一个网段用于数据库集群间的数据流通，如此设计可将数据分散为两大部分并通过两张网卡进行通信，实现了网络压力的分流（本系统并未实现此种方案，因为工作量太大，机房布线麻烦，只是一种分流想法）

1.3.2之后的几次测试结果：

我将组成openstack的六台服务器、point数据库服务器、account数据库服务器放置在了同一机架（交换机）上（这几台服务器间的网络交互最频繁）。

目前所有的服务器都在了同一个交换机下，以下是测试得到的数据与测试时的一些截图：

之后几次的测试数据：链接：https://pan.baidu.com/s/1fbiLL1d4stNAP8mqam0GSw 密码：9jl8

在第二次测试的截图中可以发现

service（10.8.59.237）模块消耗的cpu较高，已达65%，负载更是上升到了15，对于4cpu的虚拟机来说，负荷高的不是一点半点，说明此时两台4cpu8gb的虚拟机根本无法满足需求，需要大量增加service层的计算能力。

而通过对第三次测试数据的分析，可以看到在插入的速度上升到一定值后，order表开始出现主从不同步的情况，说明需要增大order表的分片数（此时是两个分片），后续打算增大到5片，同时观察服务器的cpu消耗量与负载，发现处于较低状态，说明一台高性能的服务器若只运行一个order表示及其浪费资源的情况，后续的版本测试中，会将同一个分片的主从节点都放置在一台服务器上。甚至在性能允许的情况下运行4个或6个mysql实例（后续的测试中可以看到16cpu的GEN9服务器在核心支付服务1000QPS下能从容运行6个mysql实例）。

通过分析sql数据可以得出此时的核心支付功能的qps已经上升到了250-300左右。

补充说明：

1.未对redis服务器的运行时状态进行截图，实际是其cpu消耗已经达到了60-70%，已处于比较高的状态，下个版本将会将redis从单机向cluster迁移。

2.openstack虚拟机对资源的消耗显示不直观，例如，上图中的cpu消耗只有61.2%，但实际qemu的消耗已经超过了80%甚至达到了90%，说明openstack虚拟机本身消耗了大量的计算资源，在资源有限的测试环境中，这是极大的浪费。所以在之后的测试版本中我决定弃用openstack，直接在服务器上运行。

3.现有数据不直观，后边的版本将安装dobbo-monitor监视dobbo，mycat-eye监视mycat，使资源的使用情况更直观