商品準時達，購物不抓瞎，快來學習轉轉履約時效新姿勢
1 履約時效是什么？
履約時效，簡稱Promise，對于消費者來說，可以讓他們更好地規劃自己的時間和需求，知道自己購買的商品能夠在特定時間內到達，有助于消費者做出合理的決策，并減少等待的焦慮。現在各大電商平臺都有展示，形式如下：
圖片
2 轉轉履約時效的落地方案
如下圖，在轉轉 APP 的商品列表頁、商品詳情頁、確認下單頁、商品篩選項等等都會有履約時效的身影，由此可見，日常獲取商品的預計送達時間的QPS很高，大促時足以破萬。
圖片
2.1 預計送達時間是怎么設計的 ？
為了方便大家理解，拿小王舉個例子，假設小王假期要從北京回趟老家鄭州，當天從北京到鄭州的高鐵只有三趟，分別是以下三個車次。
圖片
如果小王想要趕上在家吃晚飯，那就必須要坐上13:10從北京西站出發16:20到鄭州東站的G521次列車，那小王怎樣才能坐上這趟車呢 ？如下圖：
圖片
小王只要在11:20之前開始做午飯，就可以趕上13:10的高鐵。
對于用戶在轉轉看到的“某一時間點前支付，某天送達”是一樣的道理，先看一張用戶在轉轉下單到簽收的全流程的簡圖（如下）：
圖片
分為訂單、OMS、WMS和TMS四個模塊：
- 訂單模塊：用戶支付后會產生訂單，訂單會下發給OMS創建出庫單。
- OMS模塊：產生出庫單后，OMS會根據策略下發不同的倉儲系統（WMS），創建WMS發貨單。
- WMS模塊：產生發貨單后，倉儲人員會操作商品出庫，等待攬收。
- TMS模塊：轉轉跟其他物流公司合作，每天在倉庫有幾個固定的時間點進行攬收。
綜上所述，轉轉預計送達時間的計算邏輯為：
- 根據支付后每個系統節點的流轉時間，計算出用戶支付后多久被物流攬收。
- 根據攬收時間，調用物流公司獲取預計送達時間（這一步類比小王回家的故事中的高鐵）。
舉個例子：
圖片
得出：
- 今日7:30前下單，明天14:00送達。
- 今日12:00前下單，明天22:00送達。
- 今日 16:30前下單，后天11:00送達。
2.2 如何支撐萬級QPS
首先看一次不做任何策略的獲取預計送達時間的接口的耗時情況，如下圖：
圖片
很明顯耗時最高的地方是根據攬收時間獲取預計送達時間，其邏輯如下：
圖片
如果用戶每次請求都這么處理，顯然是有很大問題的，所以我們選擇了一個穩妥的方案處理這個點，那就是預熱，如下圖：
圖片
每天T+1根據每個倉的每個攬收時間計算到全國任意一個區的預計送達時間，存入自己的Redis中，那么新的根據攬收時間獲取預計送達時間的邏輯如下：
圖片
然后我們將其他耗時的地方通過增加一二級緩存優化，如下表格：
查詢描述 | 優化方案 | 說明 |
用戶地址轉換 | 本地緩存 | 城市名稱和code 的映射關系發放入本地緩存 |
商品尋倉 | Redis | 請求一次放入Redis |
倉庫信息填充 | 本地緩存 | 倉庫信息為低頻變化數據，數據量少，可以放入本地緩存 |
匹配攬收時間 | Redis | 配置修改是次日生效，每天定時刷入Redis |
最終，一次獲取預計送達時間的接口耗時如下：
圖片
2.3 次日達、隔日達以及三日達的篩選底層邏輯以及技術實現
想要篩選有哪些商品支持次日達的含義就是篩選哪些倉支持次日達，所以我們要做兩件事如下圖：
- 在商品標記上每個商品所在的倉庫站點。
- 提供到全國任意地址支持次日達的倉站點的能力。
圖片
如上圖，到北京能夠支持次日達的商品為SKUA、SKUE、SKUF。
難點
- 我們可以想像一下，對于用戶小王來篩選次日達的時候，系統不可能實時計算每個倉到小王所在地址的送達時間，判斷是否次日達，假設我們有3000個倉，每個倉有三個攬收時間，那么每次篩選就要計算9000次預計送達時間，肯定不可行。
如何解決
結合上文預熱預計送達時間，在其預熱任務基礎上增加預熱時效類型，如下圖：
圖片
那存儲結構怎么做？
如下圖，以全國所有的省市區作為每個key，value是list對象存到redis中。
圖片
當前存儲結構檢索效率有提升但非最優，從redis拿list后需內存過濾次日達或隔日達。可將時效類型抽取到key上為：省市區 + 時效類型，雖key數量增加但value元素減少，能使用戶檢索時響應更快，如下圖：
圖片
細心的同學應該發現了，這樣仍需內存過濾，因有時間條件。如當前 11 點，上圖首個次日達中僅青島中心倉支持，此存儲結構欠佳，需進一步改進，如下圖。
圖片
變動點：
- 存儲結構由原來的key-list轉變為key-zset，把所有倉的所有批次（最晚支付時間）聚合成一個zset，最晚支付時間作為score，倉庫信息作為value生成倒排索引。
- 原本的存儲結構是針對某個收件區的次日達，每個倉下有哪些最晚支付時間支持；現在的存儲結構是針對某個區的次日達，每個時間下有哪些倉支持。
這樣做的好處：用戶來篩選的時候定位到key，通過當前篩選時間，range一下當前zset，取出所有比當前篩選時間大的score，然后內存里去重一下即可直接獲得當前支持的倉，并且避免了大key的問題，每次操作redis只是range一個范圍，不取全量。
3 結語
轉轉履約時效系統的構建，是對用戶體驗的高度重視與不懈追求的體現。從精準的預計送達時間計算邏輯，到應對高并發的巧妙技術方案，再到不斷優化的次日達等篩選功能，轉轉始終致力于為用戶打造一個高效、可靠的購物環境。
在電商行業飛速發展的當下，履約時效已成為關鍵競爭力之一。未來，我們有理由相信，轉轉將持續完善履約時效系統，以更優質的服務滿足用戶日益增長的需求，在電商舞臺上綻放更加耀眼的光芒。
