现有架构：
对于 mysql 的操作：
- Req：一次插入
- Rsp：一次查问，一次批改
- 交易同步：一次查问，一次删除
Mysql 表构造为交易全副信息，作用为匹配交易
定时工作：
- 同步失常交易
- 同步开放平台已超时但又有响应的交易
- 长期表剩下只有申请但没有响应的交易
重放的交易只会记录一次，因为长期表依据 traceNo，appId，timestamp 匹配
批改后架构：
流程：
- 申请插入 req 的队列
- 响应蕴含残缺交易，插入 rsp，监听 rsp 队列将交易插入 es，延时异步删除 req
- 定时工作将只有申请的交易标记为“无响应”插入 rsp，再同步至 es
- 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 找不到记录。