電商平臺(tái)的積分兌換系統(tǒng)

1、idid（自增id主鍵）idid（自增id主鍵）本文就其中一個(gè)問題：設(shè)計(jì)一個(gè)電商平臺(tái)的積分兌換系統(tǒng)，來詳細(xì)闡述一下。文中會(huì)詳細(xì)指出在系統(tǒng)設(shè)計(jì)的時(shí)候要考慮哪些要點(diǎn)，給大家展示出來這類問題思考的一個(gè)過程。2、業(yè)務(wù)需求的描述假設(shè)面試官現(xiàn)在給出來對(duì)于這個(gè)電商平臺(tái)的積分兌換系統(tǒng)的相關(guān)需求如下：用戶在電商平臺(tái)里平時(shí)通過購買商品、曬單評(píng)論可以有不斷的積累積分積累到足夠的積分后，就可以在電商平臺(tái)的積分兌換頁面中，選擇使用自己的積分來兌換一些禮品需求其實(shí)就這么簡單，那么面試官說了，針對(duì)這個(gè)業(yè)務(wù)場景給出你對(duì)這個(gè)機(jī)制實(shí)現(xiàn)的思考過程以及這里要注意的一些地方。3、對(duì)業(yè)務(wù)流程的思考如何思考？首先，用戶不停的購買商品以及曬

2、單評(píng)論，會(huì)不斷的獲取積分，那么是不是需要一張積分表，專門用來存儲(chǔ)每個(gè)用戶的積分呢？沒錯(cuò)，這個(gè)表是一定需要的，可以現(xiàn)場給出下述的表結(jié)構(gòu)。積分表：user_id（用戶id）credit（積分）繼續(xù)來看，假設(shè)在積分兌換頁面，用戶選擇用自己的20000積分兌換一瓶洗發(fā)水，后臺(tái)的邏輯應(yīng)該如何設(shè)計(jì)呢？這個(gè)也是必須得現(xiàn)場給出一個(gè)思考過程的，這個(gè)其實(shí)看起來簡單，但是很多年紀(jì)較輕，經(jīng)驗(yàn)不足的朋友，可能沒法快速思考出來。首先你要用20000積分去進(jìn)行兌換，那么一定是必須要在積分表里扣減掉這20000積分的吧？所以在流程設(shè)計(jì)中，首先就得有一個(gè)20000積分扣減的過程。其次，你用這20000積分兌換了什么東西呢？所以

3、你是不是還需要一張單獨(dú)的表，叫做積分兌換記錄表，記錄下來你這個(gè)用戶本次用多少積分兌換了一件什么商品？這個(gè)積分兌換記錄表的結(jié)構(gòu)如下所示，你是不是需要在下面的那個(gè)表里插入一條記錄，說這個(gè)用戶本次用多少積分兌換了哪個(gè)商品？積分兌換表：user_id（用戶id）exchanged_credit（用于兌換的積分）product_id（兌換的商品id）最后，光是插入上述那條積分兌換記錄是不夠的，你必須得調(diào)用倉儲(chǔ)業(yè)務(wù)模塊的接口，通知倉儲(chǔ)業(yè)務(wù)模塊新增一條發(fā)貨申請(qǐng)，而且應(yīng)該是積分兌換對(duì)應(yīng)的發(fā)貨申請(qǐng)，這樣保證倉庫可以準(zhǔn)備對(duì)應(yīng)的商品進(jìn)行發(fā)貨。這個(gè)發(fā)貨申請(qǐng)大致對(duì)應(yīng)如下的表結(jié)構(gòu)：發(fā)貨申請(qǐng)表：id（自增id主鍵）type

4、（發(fā)貨類型，1：購買，2：積分兌換）credit_exchange_id積分兌換表的id）product_id（要發(fā)貨的商品id）其實(shí)這里的發(fā)貨申請(qǐng)表簡化了很多，按理說還得有發(fā)貨商品的數(shù)量等等字段，但是這里可以簡化處理也沒事，畢竟是面試現(xiàn)場。簡單畫出來這個(gè)流程大致如下所示。4“如果把上面那整個(gè)業(yè)務(wù)流程給面試官說了，就完事了嗎？當(dāng)然不是！你可以站在用戶的角度考慮一下，你是不是肯定還需要查看積分兌換的記錄？這個(gè)在積分兌換表里可以查看到你用多少積分兌換了什么商品。但是你兌換商品的物流配送進(jìn)度，能查看到嗎？不能。所以你應(yīng)該在業(yè)務(wù)流程里再考慮進(jìn)去對(duì)應(yīng)的物流配送的邏輯。通常來說一個(gè)基本的邏輯，就是在生產(chǎn)發(fā)

5、貨申請(qǐng)單的時(shí)候，需要調(diào)用第三方物流公司的接口申請(qǐng)一個(gè)物流單，這樣倉庫管理員打包準(zhǔn)備好商品，坐等物流公司商品收快遞就可以了。物流公司會(huì)根據(jù)物流單去進(jìn)行配送，這個(gè)配送地址當(dāng)然是用戶自己在電商平臺(tái)選擇的自己的某個(gè)地址。此時(shí)發(fā)貨申請(qǐng)單的表結(jié)構(gòu)是不是如下所示？發(fā)貨申請(qǐng)表：id（自增id主鍵）type（發(fā)貨類型，1：購買，2：積分兌換）credit_exchange_id（積分兌換表的id）product_id（要發(fā)貨的商品id）express_no（物流單號(hào)）所以在生產(chǎn)發(fā)貨申請(qǐng)單時(shí)，先得調(diào)用第三方物流公司的接口申請(qǐng)一個(gè)物流單，這樣發(fā)貨申請(qǐng)單中是有一個(gè)物流單號(hào)的，而且每個(gè)積分兌換記錄都通過id跟發(fā)貨申請(qǐng)單

6、關(guān)聯(lián)起來。這樣在頁面上對(duì)每個(gè)兌換記錄，是不是可以找到發(fā)貨申請(qǐng)單中的物流單號(hào)，然后根據(jù)物流單號(hào)調(diào)用第三方物流公司的接口，去獲取配送的進(jìn)度？這就是一個(gè)非常典型的業(yè)務(wù)系統(tǒng)的技術(shù)實(shí)現(xiàn)的邏輯思考，一個(gè)經(jīng)驗(yàn)豐富合格的工程師，往往都具備了一定的業(yè)務(wù)思維，可以很好的根據(jù)業(yè)務(wù)系統(tǒng)中的用戶邏輯來考慮，反推自己的系統(tǒng)技術(shù)實(shí)現(xiàn)邏輯。上述整個(gè)過程，如下圖所示：須增發(fā)炎申酒和分M簿表后指申諳妾款即榭流單宜看物源序歷出度查看物流單號(hào)查看租分科換記錄/方、新塢世療先換出錄第三方物流公司系統(tǒng)須增發(fā)炎申酒和分M簿表后指申諳妾款即榭流單宜看物源序歷出度查看物流單號(hào)查看租分科換記錄/方、新塢世療先換出錄第三方物流公司系統(tǒng)倉儲(chǔ)模提和用

7、慢塊扣減雙分理分表5iw業(yè)務(wù)流程整個(gè)捋順之后，接下來就涉及到技術(shù)的考慮了。你得考慮一下，這種業(yè)務(wù)系統(tǒng)里怎么能沒有事務(wù)呢？扣減積分、新增積分兌換記錄、新增發(fā)貨申請(qǐng)單，這三個(gè)步驟必須是要么一起完成，要么一起失敗的。也就是說，這三個(gè)步驟必須是在一個(gè)事務(wù)里的?，F(xiàn)在有一個(gè)問題，對(duì)一個(gè)電商平臺(tái)自身的業(yè)務(wù)系統(tǒng)來說，僅僅包含積分服務(wù)。但是倉儲(chǔ)服務(wù)一般是獨(dú)立部署的一套系統(tǒng)，或者是一個(gè)獨(dú)立的服務(wù)。也就是說，扣減積分和新增積分兌換記錄可以在一個(gè)服務(wù)里是一個(gè)事務(wù)，但是新增發(fā)貨申請(qǐng)單，他是在另外一個(gè)服務(wù)里的，這個(gè)事務(wù)如何保證呢？有朋友可能馬上回答：用分布式事務(wù)啊！先別急，咱們可以先用最簡單的模式來實(shí)現(xiàn)一下。比如積分服務(wù)

8、在一個(gè)事務(wù)代碼塊中，先執(zhí)行扣減積分、新增積分兌換記錄兩個(gè)步驟。然后記住，在事務(wù)代碼塊中，最后一步調(diào)用倉儲(chǔ)服務(wù)的接口，如果接口調(diào)用成功，那么就可以提交事務(wù)了。如果接口調(diào)用失敗，那么就拋異常讓事務(wù)回滾，這樣可以不可以？這個(gè)流程如下所示：積分服務(wù)事務(wù)-扣減積分-新增積分兌換記錄-調(diào)用倉儲(chǔ)服務(wù)66上述設(shè)計(jì)其實(shí)理論上是沒問題的，但是這里你忽略了一個(gè)問題，在這個(gè)業(yè)務(wù)場景中，積分服務(wù)是沒有必要同步調(diào)用倉儲(chǔ)服務(wù)的。因?yàn)榉e分兌換是一個(gè)用戶執(zhí)行的操作，假設(shè)你的倉儲(chǔ)服務(wù)在生成發(fā)貨申請(qǐng)單的時(shí)候調(diào)用第三方物流公司的接口，被卡住了，或者失敗了，怎么辦？此時(shí)可能導(dǎo)致用戶在頁面上看到積分兌換按鈕點(diǎn)擊之后，卡在那兒可能幾十秒都

9、無法執(zhí)行成功，所以這個(gè)系統(tǒng)如此設(shè)計(jì)是錯(cuò)誤的。那應(yīng)該怎么做呢？你必須得在這里引入消息中間件進(jìn)行異步化的解耦，保證用戶點(diǎn)擊積分兌換按鈕之后，盡快返回。如下圖所示：去我申席妻去我申席妻到這里就OK了嗎？還沒呢！一旦引入消息中間件之后，好處是用戶點(diǎn)擊積分兌換按鈕，直接就是在積分服務(wù)里扣減積分以及新增積分兌換記錄，然后發(fā)送一條消息到消息中間件里就結(jié)束了，速度很快，保證了用戶體驗(yàn)。但是壞處就是，萬一倉儲(chǔ)服務(wù)執(zhí)行新增發(fā)貨申請(qǐng)失敗了怎么辦？這個(gè)時(shí)候就需要引入可靠消息服務(wù)了，他需要去保證倉儲(chǔ)服務(wù)一定會(huì)完成新增發(fā)貨申請(qǐng)這個(gè)事。具體的流程如下：積分服務(wù)發(fā)送消息給可靠消息服務(wù)，可靠消息服務(wù)在消息表中新增記錄，然后發(fā)送

10、消息到MQ（消息中間件）然后倉儲(chǔ)服務(wù)消費(fèi)消息新增發(fā)貨申請(qǐng)單，如果成功就回調(diào)可靠消息服務(wù)的一個(gè)接口說自己成功了，可靠消息服務(wù)就可以更新本地消息表中的記錄狀態(tài)為成功如果倉儲(chǔ)服務(wù)長時(shí)間沒通知可靠消息服務(wù)自己成功了，可靠消息服務(wù)不停的重試再次發(fā)送消息通過這樣的設(shè)計(jì)，就可以保證可靠消息服務(wù)一定會(huì)無限次重試保證讓倉儲(chǔ)服務(wù)成功執(zhí)行。再加上重試機(jī)制后，整個(gè)流程圖如下所示：一回弼通知一可靠消現(xiàn)崩翦望最愛法.鬻疑耶捌流箱一教玷酶L畬儲(chǔ)聰.第三:鬻”司口卻liJJ新噌坦分兌糧記錄到錯(cuò)炭黃申請(qǐng)IJ1積分表現(xiàn)外兌推表斐集市潘夫查看榔流甲母宣看猊方兌攬記錄34*用戶宜看梅定配法治匿8”最后一個(gè)問題，如果倉儲(chǔ)服務(wù)卡在第三方物流系統(tǒng)申請(qǐng)物流單的環(huán)節(jié)，長時(shí)間阻塞，所以沒回調(diào)通知可靠消息服務(wù)。但是可靠消息服務(wù)過了一段時(shí)間，感覺沒收到回調(diào)通知，就自己重試發(fā)送了消息，這樣豈不是會(huì)讓倉儲(chǔ)服務(wù)新增兩條發(fā)貨申請(qǐng)單？因此我們還要保證倉儲(chǔ)服務(wù)新增發(fā)貨申請(qǐng)單的冪等性，其實(shí)也非常簡單，回顧一下發(fā)貨申請(qǐng)單表的結(jié)構(gòu)：發(fā)貨申請(qǐng)表：id（自增id主鍵）type（發(fā)貨類型，1：購買，2：積分兌換）credit_exchan