最佳实践 延迟队列干掉定时任务. 特别是跨表查询状态的定时任务

通过案例来讲两个事情
   1. 用流式干掉定时任务
   2. 如何选择合适的流.大流,小流

案例1
   背景:
        单车中都有报修的逻辑. 
原则:
    产品逻辑上尽量避免用退款来解决问题.
     把问题解决在前面.
故对于大部分的正常保修,要保证用户不需要支付.
  1. 开锁前保修,本身无费用
  2. 开锁后发现车辆有问题,关锁保修. 需要设置账单前1分钟内免费.
  3. 开锁后,骑行后已经产生了费用的用户.  
     三种策略:
     3.1 优先站在乘客利益角度: 有报修,直接减免. 会导致乘客占便宜,钻空子通过保修手段减免费用.
     3.2 优先站在公司利益角度: 乘客先投诉,投诉后再风控判断, 减免费用,或者走退款+优惠券逻辑
     3.3 中和乘客利益和公司利益: 增加乘客负担,需要乘客支付后,在进行退款.
   最终选择策略3
 实现方案:

1. 定时任务

扫描订单, 1.有效的保修单(通过风控判断) 2.有过支付. 目前两个状态是分离在两个系统的. 导致这个定时任务列表查询非常复杂. 先查再过滤.大量的查询被浪费,还要考虑流量问题. 并且集中在一定时间,凸点问题严重.

2. 流式

2.1 支付成功的流.

       支付成功后判断是否保修单.

2.2 报修的流

       报修的流,判断是否需要支付,是否支付成功. 如果否,放入到延迟队列中继续消费.

最终选择2.2的流,用小表去查大表.

案例2
    背景:
         单车中12小时内自动关闭掉订单.

    同样一个订单