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

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

一、時(shí)間輪實(shí)踐

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

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

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

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

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

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

Netty 時(shí)間輪原理如下：

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

二、檢驗(yàn)項(xiàng)目庫(kù)存實(shí)現(xiàn)方案

2.1 庫(kù)存預(yù)生成方案

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

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

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

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

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

延遲生成庫(kù)存，當(dāng)未發(fā)生庫(kù)存變更請(qǐng)求時(shí)不生成庫(kù)存，針對(duì)查詢操作，通過業(yè)務(wù)代碼構(gòu)造庫(kù)存信息，當(dāng)庫(kù)存變更時(shí)延遲生成庫(kù)存

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

2.2 延遲庫(kù)存生成方案

延遲庫(kù)存生成流程圖如下：

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

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

2.3 庫(kù)存分時(shí)

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

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

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

2.4 庫(kù)存模型

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

三、總結(jié)

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

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

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

利用分布式鎖，代碼層面對(duì)庫(kù)存進(jìn)行計(jì)算，更新 DB

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

庫(kù)存放到 Redis，Redis 扣減成功后再操作 DB

利用數(shù)據(jù)庫(kù)樂觀鎖，進(jìn)行版本號(hào)對(duì)比

庫(kù)存核對(duì)，可以開發(fā)自動(dòng)化庫(kù)存核對(duì)腳本，以任務(wù)的形式自動(dòng)核對(duì)。

總結(jié)

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

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