風(fēng)和日麗的一天遗菠，接到產(chǎn)品的一個(gè)需求：直播間需要增加主播服務(wù)套餐購買的能力，每個(gè)套餐包含n次連麥服務(wù)华蜒；用戶購買之后主播給用戶提供連麥服務(wù)辙纬，每完成一次連麥服務(wù)扣減一次。
下單和庫存扣減是經(jīng)典的后端入門項(xiàng)目叭喜，我們這里主要針對(duì)項(xiàng)目中的難點(diǎn)以及一些注意事項(xiàng)進(jìn)行詳細(xì)闡述贺拣。首先進(jìn)行簡(jiǎn)單的需求拆解，項(xiàng)目的主要模塊包括支付捂蕴、訂單纵柿、服務(wù)記錄等，我們將從這幾個(gè)模塊來針對(duì)性分析启绰。

一、下單

首先沟使，我們會(huì)給用戶展示一個(gè)商品列表頁委可，包含商品的簡(jiǎn)單介紹和商品id、商品價(jià)格等腊嗡。用戶選定某種商品之后着倾，調(diào)起購買接口，傳入商品價(jià)格和商品id燕少。

商品價(jià)格

這里注意卡者，雖然購買接口需要傳入商品的實(shí)際價(jià)格，但實(shí)際下單時(shí)商品的價(jià)格應(yīng)該以后端維護(hù)的價(jià)格為準(zhǔn)客们，主要是防止有人修改接口傳入的價(jià)格導(dǎo)致購買金額和實(shí)際金額不符崇决。另外，一般需要校驗(yàn)接口傳入價(jià)格和后端維護(hù)的價(jià)格是否一致底挫，如果不一致恒傻，返回錯(cuò)誤提示，類似“商品金額發(fā)生變化建邓，請(qǐng)刷新后重試”盈厘；如果一致，走后續(xù)的下單流程官边。

支付&訂單數(shù)據(jù)的一致性

支付系統(tǒng)的數(shù)據(jù)庫維護(hù)在支付側(cè)沸手，訂單數(shù)據(jù)維護(hù)在我們這一側(cè)外遇，屬于兩個(gè)不同的服務(wù)。不同于傳統(tǒng)的一個(gè)數(shù)據(jù)庫使用本地事務(wù)契吉，要保證兩個(gè)服務(wù)的數(shù)據(jù)一致性跳仿，我們先引入分布式事務(wù)的概念。

常用的分布式事務(wù)一致性解決方案包含二階段和三階段提交栅隐，但傳統(tǒng)的分布式事務(wù)不適用于微服務(wù)下的事務(wù)管理塔嬉，主要有以下幾點(diǎn)原因：

1、微服務(wù)之間無法直接進(jìn)行數(shù)據(jù)訪問租悄，通常通過rpc或者api進(jìn)行數(shù)據(jù)訪問谨究，無法使用統(tǒng)一的事務(wù)管理器管理RM。

2泣棋、不同微服務(wù)使用的數(shù)據(jù)源類型可能不同胶哲，可能包含NoSql等不支持事務(wù)的數(shù)據(jù)庫；

3潭辈、即使微服務(wù)的數(shù)據(jù)源都支持事務(wù)鸯屿，用一個(gè)大事務(wù)將微服務(wù)管理起來，大事務(wù)維持的時(shí)間較長(zhǎng)把敢，影響系統(tǒng)性能寄摆。

我們此處的支付和訂單采用業(yè)務(wù)補(bǔ)償模式，業(yè)務(wù)補(bǔ)償模式是指業(yè)務(wù)在調(diào)用時(shí)正常提交修赞，當(dāng)一個(gè)服務(wù)失敗時(shí)婶恼，對(duì)其依賴的所有上游服務(wù)都進(jìn)行業(yè)務(wù)補(bǔ)償操作。這種方案可以達(dá)到最終一致性的方案柏副，但此方案的實(shí)時(shí)性較差勾邦，但對(duì)于一般的支付場(chǎng)景的話可以使用。

我們這里采用的是附錄2中的重試模式割择，對(duì)于一條鏈路上的操作眷篇，通過定時(shí)任務(wù)，對(duì)每個(gè)環(huán)節(jié)不斷重試直至成功為止荔泳；對(duì)應(yīng)到我們的流程里就是下單操作蕉饼。對(duì)于需要重試的接口，需要做成冪等性换可。

二椎椰、庫存扣減

我們上架的主播服務(wù)套餐主要是n次主播連麥服務(wù)，每次用戶購買完成后沾鳄，可享受n次連麥服務(wù)慨飘，這里就涉及到一個(gè)庫存扣減的問題。我們需要保證主播的服務(wù)次數(shù)不多于用戶的付費(fèi)次數(shù)。

鑒于我們的服務(wù)qps比較小瓤的，我們這里直接使用數(shù)據(jù)庫行鎖+CAS來實(shí)現(xiàn)簡(jiǎn)單的庫存扣減不超賣的能力休弃。

數(shù)據(jù)庫行鎖是指在sql里指定庫存>0時(shí)再進(jìn)行update操作；CAS主要是指在sql里指定初始庫存圈膏，以初始庫存為update的查詢條件塔猾，如果當(dāng)前庫存等于初始庫存，再執(zhí)行update操作稽坤。我們這里只簡(jiǎn)單使用了數(shù)據(jù)庫行鎖指定條件來保證丈甸，CAS的操作暫無必要。

三尿褪、主播服務(wù)能力的限制

// todo 未完待續(xù) 等待繼續(xù)補(bǔ)充

附錄：

1.?為什么每個(gè)面試官都和數(shù)據(jù)一致性過不去睦擂？ https://juejin.cn/post/6844904162115878919?searchId=2023091914554426EA38C03A317997C38D

2. 聊聊 分布式系統(tǒng) 中的補(bǔ)償機(jī)制設(shè)計(jì)問題?https://blog.csdn.net/2301_78526383/article/details/131348926

3.?基于MySQL 和 Redis 扣減庫存的方法?https://juejin.cn/post/7230042979549478970?searchId=20230919202136A430C03E43F9E21E4C3D