现有架构：

对于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找不到记录。