建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是Tom哥。
創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的鐵西網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
做為一名程序員，發(fā)展方向大致可以分為兩個(gè)方面：一個(gè)是業(yè)務(wù)架構(gòu)，一個(gè)是技術(shù)架構(gòu)(中間件方向)。
業(yè)務(wù)架構(gòu)，取其核心關(guān)鍵詞，主要是圍繞這不同的業(yè)務(wù)場(chǎng)景、業(yè)務(wù)規(guī)則，完成業(yè)務(wù)系統(tǒng)的落地建設(shè)，為用戶提供在線化的信息服務(wù)。
既然說到業(yè)務(wù)，那方向可就多了去了，如：出行、外賣、充電寶、O2O、內(nèi)容、社交、生鮮、電商，不同的業(yè)務(wù)有不同的特點(diǎn)。
面對(duì)這么多的業(yè)務(wù)域，有沒有通用技術(shù)經(jīng)驗(yàn)可以抽取，讓我們可以以一應(yīng)百。
這里，首推電商業(yè)務(wù)，電商系統(tǒng)的復(fù)雜性很高，對(duì)高并發(fā)、高性能、高可用、高擴(kuò)展，等方面要求很高。你在其他業(yè)務(wù)中可能遇到的問題，在電商系統(tǒng)中基本都會(huì)遇到。
作為開發(fā)，希望自己成為某幾個(gè)業(yè)務(wù)領(lǐng)域的技術(shù)專家，最好能先精通電商領(lǐng)域，有很強(qiáng)的借鑒意義。對(duì)于你后續(xù)拓展熟悉其他業(yè)務(wù)領(lǐng)域的個(gè)性化玩法有很大幫助。
那么，電商領(lǐng)域的技術(shù)架構(gòu)有哪些常見問題?
一、避免重復(fù)下單
用戶快速點(diǎn)了兩次 “提交訂單” 按鈕，瀏覽器會(huì)向后端發(fā)送兩條創(chuàng)建訂單的請(qǐng)求，最終會(huì)創(chuàng)建兩條一模一樣的訂單。
解決方案：
解決方案就是采用冪等機(jī)制，多次請(qǐng)求和一次請(qǐng)求產(chǎn)生的效果是一樣的。
方案一：
利用數(shù)據(jù)庫(kù)自身特性 “主鍵唯一約束”，在插入訂單記錄時(shí)，帶上主鍵值，如果訂單重復(fù)，記錄插入會(huì)失敗。
操作過程：
- 引入一個(gè)服務(wù)，用于生成一個(gè)“全局唯一的訂單號(hào)”。
- 進(jìn)入創(chuàng)建訂單頁(yè)面時(shí)，前端請(qǐng)求該服務(wù)，預(yù)生成訂單ID。
- 提交訂單時(shí)，請(qǐng)求參數(shù)除了業(yè)務(wù)參數(shù)外，還要帶上這個(gè)預(yù)生成訂單ID。
方案二：
前端通過js腳本控制，無法解決用戶刷新提交的請(qǐng)求。另外也無法解決惡意提交。
不建議采用該方案，如果想用，也只是作為一個(gè)補(bǔ)充方案。
方案三：
前后約定附加參數(shù)校驗(yàn)。
當(dāng)用戶點(diǎn)擊購(gòu)買按鈕時(shí)，渲染下單頁(yè)面，展示商品、收貨地址、運(yùn)費(fèi)、價(jià)格等信息，同時(shí)頁(yè)面會(huì)埋上Token 信息，用戶提交訂單時(shí)，后端業(yè)務(wù)邏輯會(huì)校驗(yàn)token，有且匹配才認(rèn)為是合理請(qǐng)求。
注意：同一個(gè) Token 只能用一次，用完后立馬失效掉。
二、訂單快照，減少存儲(chǔ)成本
商品信息是可以修改的，當(dāng)用戶下單后，為了更好解決后面可能存在的買賣糾紛，創(chuàng)建訂單時(shí)會(huì)同步保存一份商品詳情信息，稱之為訂單快照。
同一件商品，會(huì)有很多用戶會(huì)購(gòu)買，如果熱銷商品，短時(shí)間就會(huì)有上萬的訂單。如果每個(gè)訂單都創(chuàng)建一份快照，存儲(chǔ)成本太高。另外商品信息雖然支持修改，但畢竟是一個(gè)低頻動(dòng)作。我們可以理解成，大部分訂單的商品快照信息都是一樣的，除非下單時(shí)用戶修改過。
如何實(shí)時(shí)識(shí)別修改動(dòng)作是解決快照成本的關(guān)鍵所在。我們采用摘要比對(duì)的方法?。創(chuàng)建訂單時(shí)，先檢查商品信息摘要是否已經(jīng)存在，如果不存在，會(huì)創(chuàng)建快照記錄。訂單明細(xì)會(huì)關(guān)聯(lián)商品的快照主鍵。
public class DigestTest {
public static void encodeStr(String data) {
String encodeS = DigestUtils.md5Hex(data);
System.out.println(encodeS);
}
public static void main(String[] args) {
String data = "網(wǎng)銷投連險(xiǎn)是保險(xiǎn)公司的一款保險(xiǎn)產(chǎn)品，在互聯(lián)網(wǎng)金融上還是很常見的。" + "比如京東天天盈，網(wǎng)易有錢零錢++。這些保險(xiǎn)削弱了保險(xiǎn)的保障功能，降低成本，從而提高保險(xiǎn)的理財(cái)功能提高理財(cái)收益。"
+ "投連險(xiǎn)基本和銀行結(jié)構(gòu)性理財(cái)產(chǎn)品一樣，信息披露度不高，但是有保險(xiǎn)公司兜底，不至于整個(gè)平臺(tái)跑路。"
+ "投資投連險(xiǎn)可以想象為投資一個(gè)起點(diǎn)低的銀行理財(cái)產(chǎn)品吧。網(wǎng)銷投連險(xiǎn)一般都受益在4-6%，不承諾保本。"
+ "經(jīng)常爆出保險(xiǎn)公司的保障型長(zhǎng)期投連險(xiǎn)出現(xiàn)投資虧損新聞，但是網(wǎng)銷短期投連險(xiǎn)投資型投連險(xiǎn)目前沒有出現(xiàn)虧損，基本也能按照預(yù)期收益兌付。"
+ "網(wǎng)銷投連險(xiǎn)安全性和收益性都比較居中，短期產(chǎn)品危險(xiǎn)系數(shù)不高，但是在債券違約的大環(huán)境下，長(zhǎng)期產(chǎn)品安全性沒有太大保障。" + "不過好在保險(xiǎn)公司沒有跑路風(fēng)險(xiǎn)，至少不會(huì)把本金損失殆盡啊。";
encodeStr(data);
}
}
由于訂單快照屬于非核心操作，即使失敗也不應(yīng)該影響用戶正常購(gòu)買流程，所以通常采用異步流程執(zhí)行。
三、購(gòu)物車，混合存儲(chǔ)
購(gòu)物車是電商系統(tǒng)的標(biāo)配功能，暫存用戶想要購(gòu)買的商品。分為添加商品、列表查看、結(jié)算下單三個(gè)動(dòng)作。
技術(shù)設(shè)計(jì)并不是特別復(fù)雜，存儲(chǔ)的信息也相對(duì)有限(用戶id、商品id、sku_id、數(shù)量、添加時(shí)間)。這里特別拿出來單講主要是用戶體驗(yàn)層面要注意幾個(gè)問題：
添加購(gòu)物車時(shí)，后端校驗(yàn)用戶未登錄，常規(guī)思路，引導(dǎo)用戶跳轉(zhuǎn)登錄頁(yè)，待登錄成功后，再添加購(gòu)物車。多了一步操作，給用戶一種強(qiáng)迫的感覺，體驗(yàn)會(huì)比較差。有沒有更好的方式?
如果細(xì)心體驗(yàn)京東、淘寶等大平臺(tái)，你會(huì)發(fā)現(xiàn)即使未登錄態(tài)也可以添加購(gòu)物車，這到底是怎么實(shí)現(xiàn)的?
細(xì)細(xì)琢磨其實(shí)原理并不復(fù)雜，服務(wù)端這邊在用戶登錄態(tài)校驗(yàn)時(shí)，做了分支路由，當(dāng)用戶未登錄時(shí)，會(huì)創(chuàng)建一個(gè)臨時(shí)Token，作為用戶的唯一標(biāo)識(shí)，購(gòu)物車數(shù)據(jù)掛載在該Token下，為了避免購(gòu)物車數(shù)據(jù)相互影響以及設(shè)計(jì)的復(fù)雜度，這里會(huì)有一個(gè)臨時(shí)購(gòu)物車表。
當(dāng)然，臨時(shí)購(gòu)物車表的數(shù)據(jù)量并不會(huì)太大，why?用戶不會(huì)一直閑著添加購(gòu)物車玩，當(dāng)用戶登錄后，查看自己的購(gòu)物車，服務(wù)端會(huì)從請(qǐng)求的cookie里查找購(gòu)物車Token標(biāo)識(shí)，并查詢臨時(shí)購(gòu)物車表是否有數(shù)據(jù)，然后合并到正式購(gòu)物車表里。
特別說明：
臨時(shí)購(gòu)物車是不是一定要在服務(wù)端存儲(chǔ)?未必。
有架構(gòu)師傾向前置存儲(chǔ)，將數(shù)據(jù)存儲(chǔ)在瀏覽器或者APP LocalStorage，這部分?jǐn)?shù)據(jù)畢竟不是共享的，但是不太好的增加了設(shè)計(jì)的復(fù)雜度。
- 客戶端需要借助本地?cái)?shù)據(jù)索引，遠(yuǎn)程請(qǐng)求查完整信息。
- 如果是登錄態(tài)，還要增加數(shù)據(jù)合并邏輯。
考慮到這兩部分?jǐn)?shù)據(jù)只是用戶標(biāo)識(shí)的差異性，所以作者還是建議統(tǒng)一存到服務(wù)端，日后即使業(yè)務(wù)邏輯變更，只需要改一處就可以了，畢竟自運(yùn)營(yíng)系統(tǒng)，良好的可維護(hù)性也需要我們非常關(guān)注的。
四、庫(kù)存超賣
常見的庫(kù)存扣減方式有：
- 下單減庫(kù)存：即當(dāng)買家下單后，在商品的總庫(kù)存中減去買家購(gòu)買數(shù)量。下單減庫(kù)存是最簡(jiǎn)單的減庫(kù)存方式，也是控制最精確的一種，下單時(shí)直接通過數(shù)據(jù)庫(kù)的事務(wù)機(jī)制控制商品庫(kù)存，這樣一定不會(huì)出現(xiàn)超賣的情況。但是你要知道，有些人下完單可能并不會(huì)付款。
- 付款減庫(kù)存：即買家下單后，并不立即減庫(kù)存，而是等到有用戶付款后才真正減庫(kù)存，否則庫(kù)存一直保留給其他買家。但因?yàn)楦犊顣r(shí)才減庫(kù)存，如果并發(fā)比較高，有可能出現(xiàn)買家下單后付不了款的情況，因?yàn)榭赡苌唐芬呀?jīng)被其他人買走了。
- 預(yù)扣庫(kù)存：這種方式相對(duì)復(fù)雜一些，買家下單后，庫(kù)存為其保留一定的時(shí)間(如 30 分鐘)，超過這個(gè)時(shí)間，庫(kù)存將會(huì)自動(dòng)釋放，釋放后其他買家就可以繼續(xù)購(gòu)買。在買家付款前，系統(tǒng)會(huì)校驗(yàn)該訂單的庫(kù)存是否還有保留：如果沒有保留，則再次嘗試預(yù)扣;如果庫(kù)存不足(也就是預(yù)扣失敗)則不允許繼續(xù)付款;如果預(yù)扣成功，則完成付款并實(shí)際地減去庫(kù)存。
至于采用哪一種減庫(kù)存方式更多是業(yè)務(wù)層面的考慮，減庫(kù)存最核心的是大并發(fā)請(qǐng)求時(shí)保證數(shù)據(jù)庫(kù)中的庫(kù)存字段值不能為負(fù)數(shù)。
方案一：
通常在扣減庫(kù)存的場(chǎng)景下使用行級(jí)鎖，通過數(shù)據(jù)庫(kù)引擎本身對(duì)記錄加鎖的控制，保證數(shù)據(jù)庫(kù)的更新的安全性，并且通過where語句的條件，保證庫(kù)存不會(huì)被減到 0 以下，也就是能夠有效的控制超賣的場(chǎng)景。
update ... set amount = amount - 1 where id = $id and amount - 1 >=0
方案二：
設(shè)置數(shù)據(jù)庫(kù)的字段數(shù)據(jù)為無符號(hào)整數(shù)，這樣減后庫(kù)存字段值小于零時(shí) SQL 語句會(huì)報(bào)錯(cuò)。
五、商家發(fā)貨，物流單更新 ABA 問題
舉個(gè)例子：
商家發(fā)貨，填寫運(yùn)單號(hào)，開始填了 123，后來發(fā)現(xiàn)填錯(cuò)了，然后又修改為 456。
此時(shí)，如果就為某種特殊場(chǎng)景埋下錯(cuò)誤伏筆，具體我們來看下：
過程：
- 開始「請(qǐng)求A」發(fā)貨，調(diào)訂單服務(wù)接口，更新運(yùn)單號(hào) 123。
- 但是響應(yīng)有點(diǎn)慢，超時(shí)了。
- 此時(shí)，商家發(fā)現(xiàn)運(yùn)單號(hào)填錯(cuò)了，發(fā)起了「請(qǐng)求B」，更新運(yùn)單號(hào)為456 ，訂單服務(wù)也響應(yīng)成功了。
- 這時(shí)，「請(qǐng)求A」觸發(fā)了重試，再次調(diào)用訂單服務(wù)，更新運(yùn)單號(hào)123，訂單服務(wù)也響應(yīng)成功了。
- 訂單服務(wù)最后保存的 運(yùn)單號(hào) 是 123。
是不是犯錯(cuò)了!!!!
那么有什么好的解決方案嗎?
很多人可能會(huì)說，不重試不就可以了，要知道重試機(jī)制 是高可用服務(wù)的重要保障手段，很多重試是框架自動(dòng)發(fā)起的。
理想的解決方案：
數(shù)據(jù)庫(kù)表引入一個(gè)額外字段 version，每次更新時(shí)，判斷表中的版本號(hào)與請(qǐng)求參數(shù)攜帶的版本號(hào)是否一致。
update order
set logistics_num = #{logistics_num} , version = #{version} + 1
where order_id= 1111 and version = #{version}
- 一致：才觸發(fā)更新。
- 不一致：說明這期間執(zhí)行過數(shù)據(jù)更新，可能會(huì)引發(fā)錯(cuò)誤，拒絕執(zhí)行。
六、賬戶余額更新，保證事務(wù)
用戶支付，我們要從買家賬戶減掉一定金額，再往賣家增加一定金額，為了保證數(shù)據(jù)的完整性、可追溯性，變更余額時(shí)，我們通常會(huì)同時(shí)插入一條記錄流水。
賬戶流水核心字段：流水ID、金額、交易雙方賬戶、交易時(shí)間戳、訂單號(hào)。
注意：賬戶流水只能新增，不能修改和刪除。流水號(hào)必須是自增的。
后續(xù)，系統(tǒng)對(duì)賬時(shí)，我們只需要對(duì)交易流水明細(xì)數(shù)據(jù)做累計(jì)即可，如果出現(xiàn)和余額不一致情況，一般以交易流水為準(zhǔn)來修復(fù)余額數(shù)據(jù)。
更新余額、記錄流水 雖屬于兩個(gè)操作，但是要保證要么都成功，要么都失敗。要做到事務(wù)。
數(shù)據(jù)庫(kù)的事務(wù)隔離級(jí)別有：讀未提交(RU)、讀已提交(RC)、可重復(fù)讀(RR)、串行化(Serializable)。
常用的隔離級(jí)別是 RC 和 RR ，因?yàn)檫@兩種隔離級(jí)別都可以避免臟讀。
當(dāng)然，如果涉及多個(gè)微服務(wù)調(diào)用，會(huì)用到分布式事務(wù)。
分布式事務(wù)，細(xì)想下也很容易理解，就是將一個(gè)大事務(wù)拆分為多個(gè)本地事務(wù)，本地事務(wù)依然借助于數(shù)據(jù)庫(kù)自身事務(wù)來解決，難點(diǎn)在于解決這個(gè)分布式一致性問題，借助重試機(jī)制，保證最終一致是我們常用的方案。
七、MySQL讀寫分離帶來的數(shù)據(jù)不一致問題
互聯(lián)網(wǎng)業(yè)務(wù)大部分都是 讀多寫少，為了提升數(shù)據(jù)庫(kù)集群的吞吐性能，我們通常會(huì)采用 主從架構(gòu)、讀寫分離。
部署一個(gè)主庫(kù)實(shí)例，客戶端請(qǐng)求所有寫操作全部寫到主庫(kù)，然后借助 MySQL 自帶的 主從同步 功能，做一些簡(jiǎn)單配置，可以近乎實(shí)時(shí)的將主庫(kù)的數(shù)據(jù)同步給 多個(gè)從庫(kù)實(shí)例，主從延遲非常小，一般不超過 1 毫秒。
客戶端請(qǐng)求的所有讀操作全部打到 從庫(kù)，借助多實(shí)例集群提升讀請(qǐng)求的整體處理能力。
這個(gè)方案看似天衣無縫，但實(shí)際有個(gè) 副作用。
主從同步雖然近乎實(shí)時(shí)，但還是有個(gè) 時(shí)間差 ，主庫(kù)數(shù)據(jù)剛更新完，但數(shù)據(jù)還沒來得及同步到從庫(kù)，后續(xù)讀請(qǐng)求直接訪問了從庫(kù)，看到的還是舊數(shù)據(jù)，影響用戶體驗(yàn)。
任何事情都不是完美的，從主同步也是一樣，沒有完美的解決方案，我們要找到其中的平衡取舍點(diǎn)。
我們以電商為例，看看如何從 產(chǎn)品層面 來化解這個(gè)問題。
為了實(shí)驗(yàn)的真實(shí)性，Tom哥 特意在淘寶下了一筆購(gòu)物訂單。
在下單確認(rèn)頁(yè)面，點(diǎn)擊購(gòu)買按鈕，進(jìn)入了支付頁(yè)面：
輸入支付寶支付密碼，進(jìn)入支付成功頁(yè)面，頁(yè)面有查看訂單詳情的入口。
點(diǎn)擊 查看交易詳情 ，才跳到真正的 訂單詳情頁(yè)，可以查看訂單的支付狀態(tài)(訂單數(shù)據(jù)取自從庫(kù))。
看懂了嗎?
我們?cè)谥Ц冻晒?，并沒有立即跳到 訂單詳情頁(yè)，而是增加了一個(gè) 無關(guān)緊要的 中間頁(yè)(支付成功頁(yè))，一是告訴你支付的結(jié)果是成功的，錢沒丟，不要擔(dān)心;另外也可以增加一些推薦商品，引流提升網(wǎng)站的GMV。最重要的，增加了一個(gè)緩沖期，為 訂單的主從庫(kù)數(shù)據(jù)同步爭(zhēng)取了更多的時(shí)間。
可謂一舉多得，其他互聯(lián)網(wǎng)業(yè)務(wù)也是類似道理。
是不是又學(xué)了一招。
八、歷史訂單，歸檔
根據(jù)二八定律，系統(tǒng)絕大部分的性能開銷花在20%的業(yè)務(wù)。數(shù)據(jù)也不例外，從數(shù)據(jù)的使用頻率來看，經(jīng)常被業(yè)務(wù)訪問的數(shù)據(jù)稱為熱點(diǎn)數(shù)據(jù);反之，稱之為冷數(shù)據(jù)。
在了解的數(shù)據(jù)的冷、熱特性后，便可以指導(dǎo)我們做一些有針對(duì)性的性能優(yōu)化。這里面有業(yè)務(wù)層面的優(yōu)化，也有技術(shù)層面的優(yōu)化。比如：電商網(wǎng)站，一般只能查詢3個(gè)月內(nèi)的訂單，如果你想看看3個(gè)月前的訂單，需要訪問歷史訂單頁(yè)面。
實(shí)現(xiàn)思路：
1.冷熱數(shù)據(jù)區(qū)分的標(biāo)準(zhǔn)是什么?要結(jié)合業(yè)務(wù)思考，可能要找產(chǎn)品同學(xué)一塊討論才能做決策，切記不要拍腦袋。以電商訂單為例：
- 方案一：以“下單時(shí)間”為標(biāo)準(zhǔn)，將3 個(gè)月前的訂單數(shù)據(jù)當(dāng)作冷數(shù)據(jù)，3 個(gè)月內(nèi)的當(dāng)作熱數(shù)據(jù)。
- 方案二：根據(jù)“訂單狀態(tài)”字段來區(qū)分，已完結(jié)的訂單當(dāng)作冷數(shù)據(jù)，未完結(jié)的訂單當(dāng)作熱數(shù)據(jù)。
- 方案三：組合方式，把下單時(shí)間 > 3 個(gè)月且狀態(tài)為“已完結(jié)”的訂單標(biāo)識(shí)為冷數(shù)據(jù)，其他的當(dāng)作熱數(shù)據(jù)。
2.如何觸發(fā)冷熱數(shù)據(jù)的分離
- 方案一：直接修改業(yè)務(wù)代碼，每次業(yè)務(wù)請(qǐng)求觸發(fā)冷熱數(shù)據(jù)判斷，根據(jù)結(jié)果路由到對(duì)應(yīng)的冷數(shù)據(jù)表或熱數(shù)據(jù)表。缺點(diǎn)：如果判斷標(biāo)準(zhǔn)是 。 時(shí)間維度，數(shù)據(jù)過期了無法主動(dòng)感知。
- 方案二：如果覺得修改業(yè)務(wù)代碼，耦合性高，不易于后期維護(hù)。可以通過監(jiān)聽數(shù)據(jù)庫(kù)變更日志 binlog 方式來觸發(fā)。
- 方案三：常用的手段是跑定時(shí)任務(wù)，一般是選擇凌晨系統(tǒng)壓力小的時(shí)候，通過跑批任務(wù)，將滿足條件的冷數(shù)據(jù)遷移到其他存儲(chǔ)介質(zhì)。在途業(yè)務(wù)表中只留下來少量的熱點(diǎn)數(shù)據(jù)。
3.如何實(shí)現(xiàn)冷熱數(shù)據(jù)分離，過程大概分為三步：
- 判斷數(shù)據(jù)是冷、還是熱。
- 將冷數(shù)據(jù)插入冷數(shù)據(jù)表中。
- 然后，從原來的熱庫(kù)中刪除遷移的數(shù)據(jù)。
4.如何使用冷熱數(shù)據(jù)
- 方案一：界面設(shè)計(jì)時(shí)會(huì)有選項(xiàng)區(qū)分，如上面舉例的電商訂單。
- 方案二：直接在業(yè)務(wù)代碼里區(qū)分。
九、訂單分庫(kù)分表，多維度查詢
如果電商網(wǎng)站的訂單數(shù)過多，我們一般會(huì)想到 分庫(kù)分表 解決策略。沒問題，這個(gè)方向是對(duì)的。
但是查詢維度很多
1.買家，查詢 我的訂單 列表，需要根據(jù) buyer_id 來查詢。
2.查看訂單詳情，需要根據(jù) order_id 來查詢。
3.賣家，查詢 我的銷售 列表，需要根據(jù) seller_id 來查詢。
而訂單分表只有一個(gè)分表鍵，如何滿足多維度 SQL 操作呢?
我們一般是基于買家維度來設(shè)計(jì)，下圖是 淘寶 的訂單列表：
一個(gè)訂單號(hào) 19 位，我們會(huì)發(fā)現(xiàn)同一個(gè)用戶不同訂單的最后 6 位都是一樣的，沒錯(cuò)，那是用戶id的后6位。
這樣，上文中 場(chǎng)景1、場(chǎng)景2 的查詢可以共性抽取， 采用 buyer_id 或 order_id 的 后六位 作為分表鍵，對(duì) 1 000 000 取模，得到買家維度的訂單分表的編號(hào)。
至于 場(chǎng)景3 賣家維度的訂單查詢，我們可以采用數(shù)據(jù)異構(gòu)方式，按seller_id 維度另外存儲(chǔ)一份數(shù)據(jù)，專門供賣家使用。
當(dāng)前題目：電商系統(tǒng)架構(gòu)，常見的九個(gè)大坑
轉(zhuǎn)載源于：http://www.fisionsoft.com.cn/article/cogshij.html
