1 履約時效是什么？

履約時效，簡稱Promise，對于消費者來說，可以讓他們更好地規(guī)劃自己的時間和需求，知道自己購買的商品能夠在特定時間內(nèi)到達，有助于消費者做出合理的決策，并減少等待的焦慮?，F(xiàn)在各大電商平臺都有展示，形式如下：

圖片

2 轉(zhuǎn)轉(zhuǎn)履約時效的落地方案

如下圖，在轉(zhuǎn)轉(zhuǎn) APP 的商品列表頁、商品詳情頁、確認下單頁、商品篩選項等等都會有履約時效的身影，由此可見，日常獲取商品的預(yù)計送達時間的QPS很高，大促時足以破萬。

圖片

2.1 預(yù)計送達時間是怎么設(shè)計的 ？

為了方便大家理解，拿小王舉個例子，假設(shè)小王假期要從北京回趟老家鄭州，當(dāng)天從北京到鄭州的高鐵只有三趟，分別是以下三個車次。

圖片

如果小王想要趕上在家吃晚飯，那就必須要坐上13:10從北京西站出發(fā)16:20到鄭州東站的G521次列車，那小王怎樣才能坐上這趟車呢 ？如下圖：

圖片

小王只要在11:20之前開始做午飯，就可以趕上13:10的高鐵。

對于用戶在轉(zhuǎn)轉(zhuǎn)看到的“某一時間點前支付，某天送達”是一樣的道理，先看一張用戶在轉(zhuǎn)轉(zhuǎn)下單到簽收的全流程的簡圖（如下）：

圖片

分為訂單、OMS、WMS和TMS四個模塊：

• 訂單模塊：用戶支付后會產(chǎn)生訂單，訂單會下發(fā)給OMS創(chuàng)建出庫單。
• OMS模塊：產(chǎn)生出庫單后，OMS會根據(jù)策略下發(fā)不同的倉儲系統(tǒng)（WMS），創(chuàng)建WMS發(fā)貨單。
• WMS模塊：產(chǎn)生發(fā)貨單后，倉儲人員會操作商品出庫，等待攬收。
• TMS模塊：轉(zhuǎn)轉(zhuǎn)跟其他物流公司合作，每天在倉庫有幾個固定的時間點進行攬收。

綜上所述，轉(zhuǎn)轉(zhuǎn)預(yù)計送達時間的計算邏輯為：

1. 根據(jù)支付后每個系統(tǒng)節(jié)點的流轉(zhuǎn)時間，計算出用戶支付后多久被物流攬收。
2. 根據(jù)攬收時間，調(diào)用物流公司獲取預(yù)計送達時間（這一步類比小王回家的故事中的高鐵）。

舉個例子：

圖片

得出：

• 今日7:30前下單，明天14:00送達。
• 今日12:00前下單，明天22:00送達。
• 今日 16:30前下單，后天11:00送達。

2.2 如何支撐萬級QPS

首先看一次不做任何策略的獲取預(yù)計送達時間的接口的耗時情況，如下圖：

圖片

很明顯耗時最高的地方是根據(jù)攬收時間獲取預(yù)計送達時間，其邏輯如下：

圖片

如果用戶每次請求都這么處理，顯然是有很大問題的，所以我們選擇了一個穩(wěn)妥的方案處理這個點，那就是預(yù)熱，如下圖：

圖片

每天T+1根據(jù)每個倉的每個攬收時間計算到全國任意一個區(qū)的預(yù)計送達時間，存入自己的Redis中，那么新的根據(jù)攬收時間獲取預(yù)計送達時間的邏輯如下：

圖片

然后我們將其他耗時的地方通過增加一二級緩存優(yōu)化，如下表格：

最終，一次獲取預(yù)計送達時間的接口耗時如下：

圖片

2.3 次日達、隔日達以及三日達的篩選底層邏輯以及技術(shù)實現(xiàn)

想要篩選有哪些商品支持次日達的含義就是篩選哪些倉支持次日達，所以我們要做兩件事如下圖：

1. 在商品標(biāo)記上每個商品所在的倉庫站點。
2. 提供到全國任意地址支持次日達的倉站點的能力。

圖片

如上圖，到北京能夠支持次日達的商品為SKUA、SKUE、SKUF。

難點

• 我們可以想像一下，對于用戶小王來篩選次日達的時候，系統(tǒng)不可能實時計算每個倉到小王所在地址的送達時間，判斷是否次日達，假設(shè)我們有3000個倉，每個倉有三個攬收時間，那么每次篩選就要計算9000次預(yù)計送達時間，肯定不可行。

如何解決

結(jié)合上文預(yù)熱預(yù)計送達時間，在其預(yù)熱任務(wù)基礎(chǔ)上增加預(yù)熱時效類型，如下圖：

圖片

那存儲結(jié)構(gòu)怎么做？

如下圖，以全國所有的省市區(qū)作為每個key，value是list對象存到redis中。

圖片

當(dāng)前存儲結(jié)構(gòu)檢索效率有提升但非最優(yōu)，從redis拿list后需內(nèi)存過濾次日達或隔日達。可將時效類型抽取到key上為：省市區(qū) + 時效類型，雖key數(shù)量增加但value元素減少，能使用戶檢索時響應(yīng)更快，如下圖：

圖片

細心的同學(xué)應(yīng)該發(fā)現(xiàn)了，這樣仍需內(nèi)存過濾，因有時間條件。如當(dāng)前 11 點，上圖首個次日達中僅青島中心倉支持，此存儲結(jié)構(gòu)欠佳，需進一步改進，如下圖。

圖片

變動點：

• 存儲結(jié)構(gòu)由原來的key-list轉(zhuǎn)變?yōu)閗ey-zset，把所有倉的所有批次（最晚支付時間）聚合成一個zset，最晚支付時間作為score，倉庫信息作為value生成倒排索引。
• 原本的存儲結(jié)構(gòu)是針對某個收件區(qū)的次日達，每個倉下有哪些最晚支付時間支持；現(xiàn)在的存儲結(jié)構(gòu)是針對某個區(qū)的次日達，每個時間下有哪些倉支持。

這樣做的好處：用戶來篩選的時候定位到key，通過當(dāng)前篩選時間，range一下當(dāng)前zset，取出所有比當(dāng)前篩選時間大的score，然后內(nèi)存里去重一下即可直接獲得當(dāng)前支持的倉，并且避免了大key的問題，每次操作redis只是range一個范圍，不取全量。

3 結(jié)語

轉(zhuǎn)轉(zhuǎn)履約時效系統(tǒng)的構(gòu)建，是對用戶體驗的高度重視與不懈追求的體現(xiàn)。從精準(zhǔn)的預(yù)計送達時間計算邏輯，到應(yīng)對高并發(fā)的巧妙技術(shù)方案，再到不斷優(yōu)化的次日達等篩選功能，轉(zhuǎn)轉(zhuǎn)始終致力于為用戶打造一個高效、可靠的購物環(huán)境。

在電商行業(yè)飛速發(fā)展的當(dāng)下，履約時效已成為關(guān)鍵競爭力之一。未來，我們有理由相信，轉(zhuǎn)轉(zhuǎn)將持續(xù)完善履約時效系統(tǒng)，以更優(yōu)質(zhì)的服務(wù)滿足用戶日益增長的需求，在電商舞臺上綻放更加耀眼的光芒。