• 重试补偿机制完善


    最近上线了一个下单平台项目,需要定时将线下的订单也推送过去,但对于补偿机制,当时是简单的进行定时,每隔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

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

  • 相关阅读:
    利用cookie改变背景色
    AsyncResult
    元组Tuple
    子查询和高效分页
    事务
    健康亮黄灯 疾病有信号
    每天学点舒压减压秘诀
    药房里买得到的传世名方:新版
    电子设备热循环和振动故障预防
    LED照明应用基础与实践
  • 原文地址:https://www.cnblogs.com/wujh88/p/9442845.html
Copyright © 2020-2023  润新知