支付交易系统优化

电子商务 B2C 案例ID：222675

💯最靓的🐷

10 年经验· 珠海众意电子商务有限公司

微信扫码沟通，客服可协助直接对接工程师；如当前档期不合，也可继续推荐相似案例作者。

案例介绍

项目描述:
好易通公司主要的业务是跨境支付平台、代收付、移动收单、监权，每天的交易量达到300万笔以上，累积一年下来的订单量已上亿笔，在初衷时的设计没按照增长率计算, 在现有的系统运行效率达不到预想的效果。

需求:
1.在现有的结构上不影响业务正常运行进行小改动达到优化效果。
2.规划长期的方向进行技术的升级。

现有系统情况:
1.一个Mysql数据库实例，主从结构，读写分离，物理硬件4核8G内存, 监控视图发现负载过高。
2.查出大量超过1秒的慢SQL,都是集中在用join连接、group by、order by、子查询，SQL语句复杂难以维护。
3.移动收单、代收付业务每天交易量在300万笔左右,高峰期集中于白天，结算系统批量任务在晚上跑, 并且接收下游的轮询操作。
4.三台应用服务器, 布满Docker应用, 监控物理(CPU,内存,磁盘IO,网络等)负载不高, 但每个响应时间达到600ms。
5.结算系统每天结算任务对300万笔数据处理耗时8-10个小时。

改造情况:
1.把数据库按业务进行垂直拆分到不同实例,用多数据源进行连接处理.目的:把group by,join等慢SQL重新写,提高SQL的质量,减轻数据库负载压力;
2.增加数据库的一个从节点, 把业务系统对数据库操作的划分, 交易系统、批量任务、查(轮)询系统、后台系统等对应不同的数据库节点。
3.对于订单、交易两个大表, 采用按日来分区, 并指定每个分区单独的数据文件, 单独的索引文件。
4 应用层某些业务从串行改成多线程并行, 不是实时交互或返回都用异步事件, 订单信息放到缓存redis上。
5．结算系统由原来串行, 改用多线程。

成果:
1.由原来请求响应时间600ms减少到30ms.
2.数据库的负载压力大大减少,回归平衡线下, 慢SQL大量减少。
3.整体的吞吐时提升5倍以上, 并且经过一点点业务划分后, 业务清晰，各业务分离，各不影响其它业务的进行。
4.结算系统由原来8-10个小时间到现在只用20分钟就能完成。