最近上线了一个下单平台项目,需要定时将线下的订单也推送过去,但对于补偿机制,当时是简单的进行定时,每隔15分钟拉取所有的未推送记录(包含上次未推成功的),放入MQ中,在消费端进行数据推送。---在消费端有另一套数据一致性机制,这里可以默认只要放入MQ,即可认定数据推送成功。

项目验收时,外请专家建议将定时机制优化,每次重试失败,下次应该隔更长时间推送,比如下次是上次的2倍,以2的N次幂进行重试,但会后询问落地方案,他也没给,只能下来慢慢琢磨,就有了这个方案:

1、线下记录表增加两个字段,推送是否成功字段status,推送次数字段reload_count,表中已有记录创建时间ins_time

2、设置筛选条件:当前时间 - 创建时间 >= 2的n次幂 * 初次间隔时长

3、定时机制仍不变,但每次定时触发的查询方法要加上上面的筛选条件

之前查询语句:

SELECT  oh.*
ta_combine_order_hdr oh
where oh.`status`=2
 and oh.ask_type = 1
limit 200

修改为:

SELECT  oh.*
ta_combine_order_hdr oh
where oh.`status`=2
 and UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(oh.ins_time) >= POW(2,oh.reload_count) *10
 and oh.ask_type = 1
limit 200

 这样能每次拉取时,都能根据当前时间和创建时间的间隔,做个过滤,一些刚重试的数据,要等待更长的时间再重试发起。

相关文章:

  • 2022-12-23
  • 2021-05-01
  • 2021-04-07
  • 2022-02-20
  • 2021-06-14
  • 2021-10-01
  • 2022-12-23
  • 2022-12-23
猜你喜欢
  • 2021-05-30
  • 2021-09-10
  • 2022-02-17
  • 2021-12-06
  • 2021-10-20
  • 2022-12-23
  • 2022-12-23
相关资源
相似解决方案