支付业务通常分订单服务器(OrderServer)和支付服务器(BillingServer)。OrderServer用于生成订单,BillingServer用于
接收第三方(微信、支付宝等)用户支付完成的回调,并通知其他业务服务器。本文仅介绍BillingServer的补单机制,补单演进分如下几个阶段。
阶段一 先天
无补单机制。BillingServer接收第三方回调后,记录入库并打印日志,通知业务服务器,根据响应的成功或失败状态,更新订单记录。
若因网络等问题通知业务服务器失败,只能通过查库和日志的方式手动补单。
阶段二 紫府
三次重试。接收第三方回调后,通知业务服务器,若返回失败,则重试通知。
阶段三 万象
自动补单机制应运而生。通过延时队列,九次补单,实现自动补单机制。简单实现如下:
延时队列因子
订单类
补单主流程
阶段四 元神
多点部署。保证各节点数据一致性,引入Redis,将补单队列由本地内存移到Redis缓存中。引入jesque依赖。
redis连接配置类
延时队列具体使用查看jesque(Github地址)
阶段五 返虚
高可靠消息队列, 如Apache Kafka(GitHub地址), 生产者与消费者约定group、topic等,第三方服务器回调后,BillingServer将订单成功的消息放到队列中,业务服务器取出。
阶段六 天仙
http与消息队列并存。通过热更新配置切换,结合ELK日志监控报警和Grafana应用监控,防止某种方式不可用。