通過案例來講兩個事情
   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小時內自動關閉掉訂單.

    同樣一個訂單