2020 年底公司和阿里健康合作了一個檢驗項目，由我司提供檢驗項目(商品)、采樣點(商戶)、庫存等底層數(shù)據(jù)，與阿里健康開發(fā)對接后在支付寶平臺進行線上預售，開發(fā)流程其中也包括訂單數(shù)據(jù)的交互。

項目開發(fā)期間踩了比較多的坑，做了很多優(yōu)化，其中也包含一些有意思的技術(shù)實現(xiàn)方案。

一、時間輪實踐

某些業(yè)務場景下，我們需要頻繁調(diào)用阿里健康接口，項目第一個版本上線后，發(fā)現(xiàn)有部分請求觸發(fā)阿里健康接口流控告警，原因是他們提供的接口在一定的時間內(nèi)只允許 N 次接口調(diào)用。針對這個問題，想到了以下幾種實現(xiàn)方式：

sleep 同步調(diào)用：對批量數(shù)據(jù)進行拆分，每條數(shù)據(jù)都 sleep 一段時間

ScheduledExecutorService 異步調(diào)用：延遲任務，通過線程池調(diào)度

HashedWheelTimer(Netty) 異步調(diào)用：將批量數(shù)據(jù)按照一定延遲時間添加到時間輪隊列中，等待調(diào)度

第 1 種方案如果同步批量數(shù)據(jù)過多，sleep 后客戶端一直得不到響應，直接 pass。第 2 種方案需要頻繁的創(chuàng)建和銷毀線程池，考慮到客戶端交互頻繁，選擇了時間輪方案。

當有任務添加到隊列中后，Netty 時間輪會開啟一個工作線程，后續(xù)所有任務的執(zhí)行都依賴這個線程，因此不會頻繁創(chuàng)建與銷毀線程資源。但是有一個缺陷是當沒有任務時，這個線程會一直空轉(zhuǎn)，只要不同時存在多個時間輪，這個空轉(zhuǎn)是可以接受的。

Netty 時間輪原理如下：

關(guān)于 Netty 時間輪設(shè)計原理，可以看下我這篇文章的總結(jié)：Netty 時間輪原理分析

二、檢驗項目庫存實現(xiàn)方案

2.1 庫存預生成方案

剛開始的庫存設(shè)計方案比較簡單，運營人員先在后臺綁定采樣點與檢驗項目的關(guān)系，然后設(shè)置排期和具體日期對應的庫存，后端接收到數(shù)據(jù)后直接入庫。

由于是在線預售業(yè)務，一般會對未來一個月內(nèi)的日期進行排期。如果有 X 家采樣點，一家采樣點綁定了 N 個項目，排期天數(shù)設(shè)置為 M 天，就需要在數(shù)據(jù)庫中保存 X * N * M 條記錄。隨著時間推移 M 越來越大，數(shù)據(jù)量也就越來越多。

這種設(shè)計方案比較容易理解，和訂單交互的流程也比較簡單，但是有一個很嚴重的問題是會預生成大量的庫存數(shù)據(jù)，業(yè)務發(fā)展不到兩個月就已經(jīng)生成了 200w+ 的數(shù)據(jù)量。

對這些數(shù)據(jù)進行分析后發(fā)現(xiàn) 95% 的數(shù)據(jù)都是無用的，于是想了以下兩種方案解決這個問題：

預先生成邏輯不變，通過定時任務掃描庫存表，刪除無效數(shù)據(jù)，無效數(shù)據(jù)主要指非未來時間且沒有庫存變更的數(shù)據(jù)

延遲生成庫存，當未發(fā)生庫存變更請求時不生成庫存，針對查詢操作，通過業(yè)務代碼構(gòu)造庫存信息，當庫存變更時延遲生成庫存

第一種方案實現(xiàn)比較簡單，原先的業(yè)務邏輯不變，只需要定義一個庫存清除任務即可。當刪除 MySQL 表數(shù)據(jù)時，這些數(shù)據(jù)所占用的空間可能會被標記為可復用，并不會釋放磁盤空間，出于這個考慮選擇了第二個方案。

2.2 延遲庫存生成方案

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

采用延遲設(shè)計方案后，數(shù)據(jù)量至少減少了 95%，考慮到并發(fā)情況，庫存延遲生成時需要利用分布式鎖防止創(chuàng)建多條庫存數(shù)據(jù)。

庫存延遲生成雖然解決了數(shù)據(jù)量的問題，但是針對一些特殊的產(chǎn)品需求，比如：修改某一天的庫存，需要保存運營現(xiàn)場數(shù)據(jù)，處理起來會比較復雜。最好的方式是權(quán)衡各個方案的利弊，找一個適合業(yè)務發(fā)展的方案。

2.3 庫存分時

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

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

為了解決這個問題，阿里健康團隊提出了分時策略，將一天劃分為幾個時間段，比如：上午十點到十二點，下午兩點到四點。這樣客戶有更多的選擇，盡可能避免出現(xiàn)上面投訴的問題。

2.4 庫存模型

• 庫存策略：分時與不分時是兩種策略，支持來回切換
• 庫存日期模板：庫存未生成時，需要根據(jù)庫存日期模板信息與分時策略構(gòu)造庫存信息
• 庫存：庫存實體
• 庫存流水：記錄庫存變更，便于排查問題與庫存核對

三、總結(jié)

溝通與表達至關(guān)重要，保持良好的溝通往往能節(jié)約大量的開發(fā)成本并減少線上問題。

設(shè)計庫存模型時由于時間緊迫，沒有具體討論相關(guān)設(shè)計方案，目前庫存相關(guān)表設(shè)計不夠扁平化，當后期處理延遲改造與分時項目時，有的細節(jié)實現(xiàn)起來比較復雜，需要冗余一些信息，導致代碼復雜度高，可讀性下降，因此需要在代碼中批注相關(guān)注釋。

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

利用分布式鎖，代碼層面對庫存進行計算，更新 DB

對庫存變更流程進行事務控制，利用數(shù)據(jù)庫拍他鎖通過 DB 計算扣減與回退庫存

庫存放到 Redis，Redis 扣減成功后再操作 DB

利用數(shù)據(jù)庫樂觀鎖，進行版本號對比

庫存核對，可以開發(fā)自動化庫存核對腳本，以任務的形式自動核對。

總結(jié)

以上是生活随笔為你收集整理的业务总结004:检验项目时间轮实践与库存实现方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。