业务总结004:检验项目时间轮实践与库存实现方案
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)方式:
第 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ù)都是無用的,于是想了以下兩種方案解決這個問題:
第一種方案實現(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ā)程度與用戶體驗,選擇適中的方案。
庫存核對,可以開發(fā)自動化庫存核對腳本,以任務的形式自動核對。
總結(jié)
以上是生活随笔為你收集整理的业务总结004:检验项目时间轮实践与库存实现方案的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 信用卡设置有效期的原因
- 下一篇: 工作上的一些思考