業務總結004 檢驗專案時間輪實踐與庫存實現方案

2020 年底公司和阿里健康合作了乙個檢驗專案，由我司提供檢驗專案(商品)、取樣點(商戶)、庫存等底層資料，與阿里健康開發對接後在支付寶平台進行線上預售，開發流程其中也包括訂單資料的互動。

專案開發期間踩了比較多的坑，做了很多優化，其中也包含一些有意思的技術實現方案。

某些業務場景下，我們需要頻繁呼叫阿里健康介面，專案第乙個版本上線後，發現有部分請求觸發阿里健康介面流控告警，原因是他們提供的介面在一定的時間內只允許 n 次介面呼叫。針對這個問題，想到了以下幾種實現方式：

sleep 同步呼叫：對批量資料進行拆分，每條資料都 sleep 一段時間

scheduledexecutorservice 非同步呼叫：延遲任務，通過執行緒池排程

hashedwheeltimer(netty) 非同步呼叫：將批量資料按照一定延遲時間新增到時間輪佇列中，等待排程

第 1 種方案如果同步批量資料過多，sleep 後客戶端一直得不到響應，直接 pass。第 2 種方案需要頻繁的建立和銷毀執行緒池，考慮到客戶端互動頻繁，選擇了時間輪方案。

當有任務新增到佇列中後，netty 時間輪會開啟乙個工作執行緒，後續所有任務的執行都依賴這個執行緒，因此不會頻繁建立與銷毀執行緒資源。但是有乙個缺陷是當沒有任務時，這個執行緒會一直空轉，只要不同時存在多個時間輪，這個空轉是可以接受的。

netty 時間輪原理如下：

關於 netty 時間輪設計原理，可以看下我這篇文章的總結：netty 時間輪原理分析

2.1 庫存預生成方案

剛開始的庫存設計方案比較簡單，運營人員先在後台繫結取樣點與檢驗專案的關係，然後設定排期和具體日期對應的庫存，後端接收到資料後直接入庫。

這種設計方案比較容易理解，和訂單互動的流程也比較簡單，但是有乙個很嚴重的問題是會預生成大量的庫存資料，業務發展不到兩個月就已經生成了 200w+ 的資料量。

對這些資料進行分析後發現 95% 的資料都是無用的，於是想了以下兩種方案解決這個問題：

預先生成邏輯不變，通過定時任務掃瞄庫存表，刪除無效資料，無效資料主要指非未來時間且沒有庫存變更的資料

延遲生成庫存，當未發生庫存變更請求時不生成庫存，針對查詢操作，通過業務**構造庫存資訊，當庫存變更時延遲生成庫存

第一種方案實現比較簡單，原先的業務邏輯不變，只需要定義乙個庫存清除任務即可。當刪除 mysql 表資料時，這些資料所占用的空間可能會被標記為可復用，並不會釋放磁碟空間，出於這個考慮選擇了第二個方案。

2.2 延遲庫存生成方案

延遲庫存生成流程圖如下：

採用延遲設計方案後，資料量至少減少了 95%，考慮到併發情況，庫存延遲生成時需要利用分布式鎖防止建立多條庫存資料。

庫存延遲生成雖然解決了資料量的問題，但是針對一些特殊的產品需求，比如：修改某一天的庫存，需要儲存運營現場資料，處理起來會比較複雜。最好的方式是權衡各個方案的利弊，找乙個適合業務發展的方案。

2.3 庫存分時

後來和阿里健康對接了乙個上門服務業務，這個業務起來了，單量也越來越多，退單率也高了起來，甚至收到了比較多的客訴，原因是使用者只能約某一天的訂單，但是並不知道線下人員什麼時間段上門。

有的客戶約了明天的訂單，但是客戶可能只有明天上午有時間，線下人員如果下午上門服務，這時候客戶就不高興了，不高興了怎麼辦，總得找個方式發洩，投訴。

2.4 庫存模型

溝通與表達至關重要，保持良好的溝通往往能節約大量的開發成本並減少線上問題。

設計庫存模型時由於時間緊迫，沒有具體討論相關設計方案，目前庫存相關表設計不夠扁平化，當後期處理延遲改造與分時專案時，有的細節實現起來比較複雜，需要冗餘一些資訊，導致**複雜度高，可讀性下降，因此需要在**中批註相關注釋。

庫存變更存在併發問題，延遲生成時通過分布式鎖進行控制，庫存扣減與回退時有以下處理方案。應該綜合考慮併發程度與使用者體驗，選擇適中的方案。

利用分布式鎖，**層面對庫存進行計算，更新 db

對庫存變更流程進行事務控制，利用資料庫拍他鎖通過 db 計算扣減與回退庫存

庫存放到 redis，redis 扣減成功後再操作 db

利用資料庫樂觀鎖，進行版本號對比

庫存核對，可以開發自動化庫存核對指令碼，以任務的形式自動核對。