网关交易同步优化

现有架构:

对于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找不到记录。
SegmentFault博客
我还没有学会写个人说明!
上一篇

(数据科学学习手札108)Python+Dash快速web应用开发——静态部件篇(上)

下一篇

[Python] Matplotlib 图表的绘制和美化技巧

你也可能喜欢

评论已经被关闭。

插入图片