高流量发布会，保障支付系统稳定运行感想

背景

当某个时间点准备进行高流量发布会、电商活动时，支付系统需要提前做好准备。

目标
1、提高服务相关接口的qps和tps；

2、保障服务稳定运行；

3、提前发现可能存在的风险，避免系统因为某个功能瓶颈，导致系统出问题；

4、实现99.99%的高可用性，确保关键路径（如支付核心链路）基本零中断；

5、降低端到端延迟，支付核心链路平均响应时间控制在200ms内；

6、建立分钟级故障熔断与恢复机制；

策略
1、精细化流量预估，基于历史活动数据进行预估；服务机器扩容，nginx层扩容，提高请求的qps；

2、核心交易系统不做商户查单的功能，都迁移到query系统去，减少核心交易系统的压力；

3、根据业务场景，进行异步线程池隔离，保障交易服务核心链路的稳定性；

4、进行功能降级，设置开关，非必要功能（涉及写数据表的），活动期间，可以暂时关闭，缓解数据库的压力；

5、进行服务接口限流，服务需要进行自我保护，防止流量过大时，压垮服务；

注意：如果是要防黄牛，可能涉及nginx层ip限流。注意要考虑到渠道进行支付成功通知的场景，避免部分支付成功通知请求被限流，导致支付成功处理延迟，用户出现重复支付的场景；

6、进行全链路压测，探底服务相关接口的qps和tps，限流策略是否生效；

7、渠道侧都有限流策略，需要提前跟渠道侧沟通好，要求渠道侧临时提高下他们接口的限流配置，支持更多的qps；

8、提前准备好渠道侧接口出现限流时，都会是哪些表现，对应的请求响应日志，做好监控；

9、当出现大量退款导致触发渠道侧退款接口限流时，要确认定时任务能够自动进行原单退款重试；

10、与上游服务沟通清楚，都涉及到哪些场景的调用，避免出现漏掉相关接口的评估，导致没提前进行准备，系统扛不住；

11、通知商户服务，要保障能及时通知到商户，订单支付成功了。对于重点商户，都进行httpClient线程池隔离，避免因为某个商户通知处理慢，导致影响其他重点商户的通知处理。
下游接收支付成功通知的服务，也要进行压测，看能支持住多少tps的处理能力，做好限流保护；

12、做好各模块的预案，进行生产演练。