网关交易同步优化

现有架构：

对于mysql的操作：

• Req：一次插入
• Rsp：一次查询，一次修改
• 交易同步：一次查询，一次删除

Mysql表结构为交易全部信息，作用为匹配交易

定时任务：

• 同步正常交易
• 同步开放平台已超时但又有响应的交易
• 临时表剩下只有请求但没有响应的交易

重放的交易只会记录一次，因为临时表根据traceNo，appId，timestamp匹配

修改后架构：

流程：

1. 请求插入req的队列
2. 响应包含完整交易，插入rsp，监听rsp队列将交易插入es，延时异步删除req
3. 定时任务将只有请求的交易标记为“无响应”插入rsp，再同步至es
4. Flink监听rsp进行交易告警

对于mysql的操作：

• Req：一次插入
• Rsp：延时删除
• 定时任务：一次查询

优势：

• 流程简单，没有复杂的匹配规则
• 可记录所有的交易，包含重放交易
• Mysql表结构为交易请求，作用为记录请求，如果需要添加交易字段，不用修改表结构。即扩展性更好
• 实时性更好，对mysql压力更小
• 告警可用flink进行处理，可配置更复杂的规则

特殊的交易情况：

• 正常情况下每个请求在开放平台都有响应，不管是超时还是重放的交易，响应应该在mysq中找到请求信息。
• 请求无任何响应（gateway接受请求后突然挂掉）：定时任务查看1分钟（gateway超时时间）前在mysql的请求，标记为未响应（在es中查询？）插入rsp队列
• 响应在mysql未找到请求（响应比请求先到mysql，网关超时又来了业务响应）：延时删除
• 请求标记为网关超时又来了业务响应（mq超时但响应又来，业务响应在mysql中找不req）：Es记录两条流水号相同的交易，一条为网关超时，一条没有请求信息
• 重复的交易，即相同的请求参数重复发（req插入mysql时可能会报错相同ID，rsp删除mysql时找不到req）：es全部记录，不管是否重复

响应来了的删除策略：

• Req来了后插入mysql，收到rsp后删除
• 如果响应查不到请求，过五百毫秒再查，避免响应比请求先入库的情况；
• 如果没有，应该为业务已超时但响应又回来的交易，再在es查；
• 如果还没有，标记为mysql找不到记录。