作者简介：上海某国企技术专家、架构师，拥有多家大厂一线后端研发经验，各大技术社区领军专家博主，编程精选网创始人。拥有丰富的团队领导经验，对业务架构和解决方案有深厚的积累。负责：中央/分布式预约系统的性能优化；活动、优惠券等营销中平台建设；交易平台和数据中台的架构和开发设计。目前主要关注降低软件复杂度设计和构建高可用性系统。 ”

3.2 业务流程

当业务发起消费时，首先进入支付核心初始化流程、风控风险识别、通道路由、通道网关消息组装、提交、通道响应。异步事务发送消息到MQ集群，任务作业监控消息，放置缓存，定时任务拉取状态查询。业务方通过查询服务查询交易的支付状态。

3.3 预优化水平方向

3.4 预优化垂直拆分 3.5 任务运行

内部查询策略设计为两队列一批处理：

3.6 分片策略

任务分片：将任务分配到不同的机器上运行，既解决了单机算力上限的问题，又减少了部分任务失败对整个系统的影响。

-job 不直接提供数据处理功能，只是为每个运行的作业服务器分配分片项（即Job实例，一台机器上部署的多个Job实例也可以分片）。开发需要自己处理分片项和真实数据的对应关系。

数据分片：订单号取模存储（zset）

3.7 数据结构设计思路 zset元素数据过期，需要业务自行处理。检测机制可以单独建立，也可以在每次业务执行时进行判断。如果过期了，就会被移除，否则集合会越来越大。 4 高可用性设计 4.1 通道隔离

高并发访问下，系统所依赖的通道的稳定性对系统影响很大。外部依赖存在很多不可控因素，比如网络连接速度慢、资源突然繁忙而暂时不可用、容错开源框架的选择、隔离方案的选择等。

4.2 查询网关

在交易系统中，查询业务量一般是支付业务的6倍，甚至更高，这对查询服务性能提出了更高的要求。减少对核心交易的影响，提高稳定性。

4.3 渠道商户缓存

通道信息（机构号、商户号、密钥等）为静态信息，首次使用时存储在分布式缓存系统中（设置TTL是为了防止僵尸数据）。同时增加了手动修改的入口，方便人工干预。

QPS较高的服务，基本上这种场景下，你的服务也会被拉下来。如果上游服务没有设置合理的超时时间，故障就会蔓延。这种故障逐渐放大的过程就是业务雪崩效应。采用容错框架来解决这个问题。通过命令模式，将每一类业务请求封装成对应的命令请求。每个命令请求对应一个线程池，创建好的线程池放入其中。

虽然线程池提供了线程隔离，但必须有超时设置，不能无限期阻塞，使线程池保持饱和状态。

线程监控

实时展示各业务的线程池资源，并以此作为研发参考，评估资源是否充足、机器资源是否需要升级等：

2.0全面对接内部监控平台，重点关注：

5 规划

程序员终身学习网站编程严选网（）现已上线！点击阅读原文并访问网站！

欢迎长按图片加好友，我会第一时间与大家分享软件行业动态、面试资源、学习方法等。

添加好友备注【技术群交流】，带您进群，获取更多教程资源。