? 商城系統(tǒng)下單庫(kù)存管控系列雜記（二）（并發(fā)安全和性能部分延伸） ? ? 前言 ? 參與過(guò)幾個(gè)中小型商城系統(tǒng)的開(kāi)發(fā)，隨著時(shí)間的增長(zhǎng)，以及對(duì)系統(tǒng)的深入研究和測(cè)試，發(fā)現(xiàn)確實(shí)有很多值得推敲和商榷的地方（總有很多重要細(xì)節(jié)存在缺陷）。基于商城系統(tǒng)，無(wú)論規(guī)模大小，或者本身是否分布架構(gòu)，個(gè)人覺(jué)得最核心的一環(huán)就是下單模塊，而這里面更相關(guān)和棘手的一些設(shè)計(jì)和問(wèn)題，大多時(shí)候都涉及庫(kù)存系統(tǒng)。想想之前跟某人的交流，他精辟點(diǎn)評(píng)“庫(kù)存管控做得好，系統(tǒng)設(shè)計(jì)就成功了一半”，自己頗有認(rèn)同。圍繞這個(gè)點(diǎn)，結(jié)合目前經(jīng)驗(yàn)和朋友間的交流（包括近來(lái)參閱其他文章提到的點(diǎn)），閑來(lái)做些整理記錄，也許不太完整，但總歸希望能有更多啟發(fā)，自己往后也會(huì)重新揣摩。當(dāng)然，文中若有不妥，歡迎指正。 ? ? 正文 ? 談及”下單“，就立刻想起前年參與的一個(gè)基于微信的小型商城系統(tǒng)，里面下單這塊本身談不上復(fù)雜，大概可以這樣描述提交過(guò)程：用戶提交商品訂單，系統(tǒng)核對(duì)用戶提交的訂單，校驗(yàn)商品（商品價(jià)格、優(yōu)惠折扣、積分等），檢測(cè)附屬信息（地址運(yùn)費(fèi)等），一切Pass，操作庫(kù)存（記錄/預(yù)扣），生成訂單及相關(guān)聯(lián)的明細(xì)數(shù)據(jù)。此時(shí)下單Ok，那么后續(xù)則是等待用戶的及時(shí)付款了。 ? 然而，看似如此簡(jiǎn)單的一個(gè)流程，放在并發(fā)環(huán)境下，就暴露了足夠多的問(wèn)題。深入進(jìn)去，首當(dāng)其沖的就是庫(kù)存管控。包括但不限于庫(kù)存的扣減方式，如何安全操作，以及減少性能損耗等等。 ? 【為了方便獨(dú)立成文，原諒在內(nèi)容排版上的一點(diǎn)點(diǎn)個(gè)人強(qiáng)迫癥】 【本文內(nèi)容由上一篇擴(kuò)展論述（詳見(jiàn)：商城系統(tǒng)下單庫(kù)存管控系列雜記（一） http://www.cnblogs.com/bsfz/p/7801980.html）】 ? ? 四、闡述關(guān)于并發(fā)環(huán)境中庫(kù)存管控的一些案例問(wèn)題，以及涉及到的相關(guān)技術(shù)實(shí)現(xiàn)細(xì)節(jié) ? 庫(kù)存扣減，簡(jiǎn)單來(lái)說(shuō)，就是在對(duì)應(yīng)的存儲(chǔ)器中（數(shù)據(jù)庫(kù)或者持久緩存）將對(duì)應(yīng)商品的數(shù)量減少。 數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)，一般包含但不限于 商品主表，商品規(guī)格表，商品庫(kù)存表，商品庫(kù)存流水日志表等等。但這里為了方便后續(xù)闡述，將其簡(jiǎn)化為一張表——商品表（PT），該表僅包含兩個(gè)字段——商品主鍵（id）和商品庫(kù)存（qty?）。 ? 依然以商品P舉例，其主鍵為pid，那么就是在下單時(shí)，將歷史庫(kù)存S修改為 S -N。具體到SQL里，原始操作大概是這樣（以SQL SERVER 舉例）： update PT set qty = (S - N) where id = pid ; ? 這是以前的最原始的操作方式，單粒度的看，也沒(méi)什么大礙。然而，放在一個(gè)并發(fā)環(huán)境中，則立馬暴露出諸多問(wèn)題。 ? 假定在同一時(shí)刻，有兩個(gè)用戶提交了訂單，一樣的操作，一樣的商品，一樣的數(shù)量。那么最終商品P的庫(kù)存數(shù)量應(yīng)該為 S - N - N。而執(zhí)行上面的SQL，因?yàn)椴l(fā)，導(dǎo)致兩次查詢到歷史庫(kù)存均是S（應(yīng)該至少有一次qty為S - N），則更新完畢后，商品數(shù)量最終是 S - N。這種致命性的Bug，也屬于超賣（雖然不會(huì)扣為負(fù)數(shù)），如果放在線上，簡(jiǎn)直是一個(gè)定時(shí)炸彈，不，還不僅僅只是這一個(gè)定時(shí)炸彈。 ? 圍繞解決這樣的問(wèn)題，考慮到并發(fā)安全以及并發(fā)性能，產(chǎn)生了各種解決方案。大體基于兩種機(jī)制：悲觀鎖和樂(lè)觀鎖。在諸多場(chǎng)景里，基于每種鎖，都有配套的輔助手段，以及各自不同的側(cè)重取舍和相關(guān)實(shí)現(xiàn)。 ? ? 4.1 使用悲觀鎖的理念，實(shí)際就是在并發(fā)的關(guān)鍵地方，強(qiáng)制將“類似并行”改為串行，相關(guān)的一些處理方式： ? 4.1.1? 數(shù)據(jù)庫(kù)鎖，利用數(shù)據(jù)庫(kù)的自身的事務(wù)隔離機(jī)制（Isolation），進(jìn)行排他操作。 ? ?????? 4.1.1.1 　　極端的在查詢時(shí)，直接開(kāi)啟事務(wù)設(shè)置行鎖（rowlock）。串行目的是達(dá)到了，但即時(shí)在單機(jī)系統(tǒng)中，也無(wú)法承受巨大的性能損耗。并且最終的超賣問(wèn)題也沒(méi)有解決，非常不推薦。 ? 4.1.1.2 　　僅利用數(shù)據(jù)庫(kù)在update時(shí)造成的排他鎖，使真實(shí)更新時(shí)串行，并增加庫(kù)存判斷，若庫(kù)存發(fā)生變動(dòng)，則更新無(wú)效，超賣問(wèn)題也不會(huì)發(fā)生。譬如（以SQL SERVER 舉例）： 　　update PT set qty = qty - N? where id = pid and qty >= N; ? 　　嚴(yán)格來(lái)講，這依然是一個(gè)較粗的粒度，但不得不說(shuō)，在單機(jī)環(huán)境下有一定的可行性。同時(shí)，需要考慮高并發(fā)情況下（例如商戶舉辦活動(dòng)，同時(shí)參與用戶過(guò)多）存在一定性能瓶頸，數(shù)據(jù)庫(kù)IO負(fù)載過(guò)大。此時(shí)需要結(jié)合其他方案，包括增加上層緩存層等。甚至部分場(chǎng)景需要單獨(dú)設(shè)計(jì)一套流程（例如秒殺搶購(gòu)場(chǎng)景，首先就是應(yīng)用到隊(duì)列，否則網(wǎng)站可能沒(méi)崩潰在并發(fā)請(qǐng)求數(shù)上，而是直接掛在了DB上，后面會(huì)有相關(guān)闡述） ? 4.1.2? 使用程序鎖（單機(jī)線程鎖和分布式調(diào)度鎖），使部分關(guān)鍵代碼串行。 ? 4.1.2.1 　　極端的直接使用程序自帶的全局線程鎖，以.NET Framewok 舉例，里面有各級(jí)粒度的鎖，常用的輕量鎖有l(wèi)ock（Mointor語(yǔ)法糖）、SpinLock（自旋鎖）。使用它們，最早大概是應(yīng)用在“單例模式”的構(gòu)建，原理本身不復(fù)雜，使用也方便，并且也達(dá)到了串行的目的。 　　然而，放在下單庫(kù)存管控這里，串行的卻是所有用戶進(jìn)行任意商品下單操作，打擊面太大（甚至直接上升到全面打擊），對(duì)性能造成極大影響，不可行，不過(guò)多延伸，也不推薦。（曾經(jīng)優(yōu)化一個(gè)舊項(xiàng)目里的模塊，初步Review代碼時(shí)就發(fā)現(xiàn)了幾處不經(jīng)意的地方竟直接使用了這種寫法，而開(kāi)發(fā)人員還是兩名老員工）。 ? 4.1.2.2 　　構(gòu)建一個(gè)本地的線程鎖管理器（這里稱為L(zhǎng)ockerManage），統(tǒng)一分配鎖對(duì)象（等待對(duì)象）。其本質(zhì)是針對(duì)上面4.1.2.1方式的包裝處理，實(shí)現(xiàn)類似“工廠模式”的機(jī)制。主要是通過(guò)它來(lái)生產(chǎn)具有唯一特征的Object對(duì)象，這個(gè)對(duì)象將會(huì)作為鎖對(duì)象資源返回給Monitor等調(diào)用，并具有一定的使用時(shí)效，每次生成后保存在內(nèi)部的線程安全的集合里，同時(shí)具有自動(dòng)銷毀機(jī)制（運(yùn)行一個(gè)獨(dú)立線程，定時(shí)檢查清理）。其中有個(gè)小細(xì)節(jié)，為了優(yōu)化管理器內(nèi)部的并發(fā)問(wèn)題，開(kāi)始使用的是.NET Framewok 里自帶的線程安全的字典集合（ConcurrentDictionary），后來(lái)經(jīng)測(cè)試，發(fā)現(xiàn)并發(fā)處理并不理想，后面便換了其他方案（讀寫分離）。回歸到下單這里，這里依然以商品P為例，首先調(diào)用LockerManage，獲取一個(gè)以當(dāng)前商品主鍵為標(biāo)識(shí)的Object對(duì)象，然后在庫(kù)存的預(yù)扣核對(duì)時(shí)，使用Mointor加鎖處理。（當(dāng)然，這里是本機(jī)鎖，后續(xù)有說(shuō)明）。這種方式對(duì)比數(shù)據(jù)庫(kù)鎖，則是降低數(shù)據(jù)庫(kù)的操作，而將壓力大部分轉(zhuǎn)移到了程序上，但相對(duì)可以更靈活的去操控。 ? 4.1.2.3 　　使用分布式鎖。上面的普通程序鎖作為單機(jī)的存在，決定了其在分布式架構(gòu)上的不可控性，而這時(shí)就有了分布式調(diào)度鎖。它主要是為了方便解決分布式情況下，在多個(gè)Web程序內(nèi)實(shí)現(xiàn)并發(fā)線程的一個(gè)管控。值得一提的是，這個(gè)“輪子”并不需要手動(dòng)重新創(chuàng)造，目前市面上已經(jīng)有相對(duì)成熟的解決方案，如利用Zookeeper和Redis。在AutumnBing項(xiàng)目中，當(dāng)時(shí)選擇的是Redis，使用的驅(qū)動(dòng)庫(kù)是StackExchange.Redis。（后續(xù)聽(tīng)到朋友提到Zookeeper更適合充當(dāng)這樣的角色，但由于目前自己還沒(méi)有太多涉獵研究，暫時(shí)持保留態(tài)度）。當(dāng)然，純粹采用分布式鎖，自然調(diào)用性能會(huì)有更多損耗。而相對(duì)更合理的做法，是結(jié)合單機(jī)鎖搭配應(yīng)用（試討論，分布式鎖放置外層，單機(jī)鎖放置內(nèi)部，每個(gè)站點(diǎn)各自維護(hù)）。 ? ? 4.2? 遵循樂(lè)觀鎖的理念，則是默許不會(huì)有太大的并發(fā)問(wèn)題（聚焦在小粒度的商品P上，則是認(rèn)為大多數(shù)情況下P不會(huì)被同時(shí)消費(fèi)），“放任”線程的執(zhí)行，不做管控。但是會(huì)在關(guān)鍵地方進(jìn)行版本核對(duì)，假如失敗，則內(nèi)部重試或拋出失敗信號(hào)。 ? ? 4.2.1? 數(shù)據(jù)庫(kù)層面上，增加顯式的版本號(hào)字段（ver）。 ? 　　購(gòu)買商品P，下單這里需要獲取到當(dāng)前時(shí)刻對(duì)應(yīng)的庫(kù)存qty01，當(dāng)前記錄是版本ver01，然后在真實(shí)更新時(shí)，再次查詢商品P的庫(kù)存，以及對(duì)應(yīng)的當(dāng)前的版本ver02，如果 ver01 == ver02，那么可以更新。否則，當(dāng)前數(shù)據(jù)已因并發(fā)被修改，無(wú)法更新。這更像是數(shù)據(jù)庫(kù)的“不可重復(fù)讀”，而出現(xiàn)這種情況后（高并發(fā)情況下，出現(xiàn)概率直線上升），必須附有關(guān)聯(lián)的內(nèi)部嘗試機(jī)制（注意保證冪等性）。 這是一種實(shí)現(xiàn)并發(fā)管控的方案，但只適合存在并發(fā)，但并發(fā)量不太大的情況，否則，一是違背樂(lè)觀鎖的理念初衷，二是整體性能以及體驗(yàn)會(huì)大打折扣。 ? ? 4.2.2? 程序控制上，采取隊(duì)列（queue）方式，進(jìn)行相對(duì)集中化預(yù)受理，然后分發(fā)逐個(gè)處理。 ? 　　需要聲明，這里本身執(zhí)行原理，其實(shí)質(zhì)依然離不開(kāi)類似悲觀鎖的管控性質(zhì)，一是入隊(duì)時(shí)需要有個(gè)小粒度的鎖機(jī)制保證串行（當(dāng)然也可以是其他方式，這是隊(duì)列內(nèi)部的管控機(jī)制之一），二是出隊(duì)，例如分發(fā)到不同服務(wù)上去處理，最終也是一個(gè)一個(gè)在操作更新（依然是某種程度上的串行）。但是，作為用戶下單的提交，本身是保證了樂(lè)觀的態(tài)度，一股腦“同時(shí)”或者“快速”接收，然后再考慮如何告知處理。 ? 　　 由于單機(jī)隊(duì)列的應(yīng)用，會(huì)出現(xiàn)更多類似上面單機(jī)鎖的一些額外問(wèn)題，這里不推薦（當(dāng)然你可以結(jié)合），也不做擴(kuò)展說(shuō)明。下面僅就分布式隊(duì)列在大方向上舉例闡述。 ? 　　如何采用分布式隊(duì)列來(lái)實(shí)現(xiàn)下單以及庫(kù)存管控呢？依然以商品P為例，用戶同時(shí)購(gòu)買商品P，本身是一個(gè)并發(fā)操作，但是我們可以將一系列的請(qǐng)求商品扣減數(shù)據(jù)Push到一個(gè)隊(duì)列中（生產(chǎn)者開(kāi)始生產(chǎn)），然后由專門的線程進(jìn)行訂閱消費(fèi)（消費(fèi)者開(kāi)始消費(fèi)）。暫且假定為一個(gè)線程在消費(fèi)，那么該線程具體消費(fèi)時(shí)，逐個(gè)將商品數(shù)據(jù)出隊(duì)，進(jìn)行庫(kù)存扣減，這里必然不會(huì)出現(xiàn)并發(fā)。消費(fèi)完畢，無(wú)論扣除庫(kù)存邏輯上是成功還是失敗，均給出一個(gè)應(yīng)答（ACK）。注意這里并沒(méi)有過(guò)多的拆分邏輯，而是將下單的一些操作扔進(jìn)一個(gè)隊(duì)列中，使用專門的程序去逐個(gè)或者逐幾個(gè)（分批）處理。實(shí)際使用往往是根據(jù)業(yè)務(wù)，做更小粒度的拆分和調(diào)整。另外，關(guān)于技術(shù)框架選型，目前各類開(kāi)源成熟的MQ項(xiàng)目比比皆是，個(gè)人圈子里了解到最多的還是 RabbitMQ，對(duì)于多個(gè)生產(chǎn)者以及與之配合的多個(gè)消費(fèi)者，還有應(yīng)答處理機(jī)制，包括本身的性能和高可用性，均極其出色。額外的，關(guān)于web前端，很多時(shí)候則是需要配合一些輪詢機(jī)制來(lái)檢查訂單狀態(tài)（當(dāng)然，輪詢這里也有一些具體細(xì)節(jié)，比如異步體驗(yàn)、輪詢時(shí)長(zhǎng)和狀態(tài)重置等考慮） ? ? ? 五、涉及到分布式SOA架構(gòu)體系（包括如今基于SOA開(kāi)始流行的微服務(wù)架構(gòu)）情況下的一些額外考慮。 ? 首先聲明，個(gè)人認(rèn)為SOA只是一種架構(gòu)上的抽離設(shè)計(jì)，本身與論述的庫(kù)存管控沒(méi)有直接關(guān)系。但這里以庫(kù)存管控為例，也有需要額外考慮的地方。 ? 我們假定在一個(gè)下單API中，包含了3個(gè)獨(dú)立的API接口：A-積分扣減API，B-優(yōu)惠券扣減API，C-庫(kù)存扣減API。考慮一種情況：假定庫(kù)存本身可以被合法扣除，并且執(zhí)行C成功了，但是發(fā)生了其他問(wèn)題，A或者B執(zhí)行失敗了，那庫(kù)存該如何回滾。 ? 必須糾正的是，在這樣一個(gè)耦合性系統(tǒng)場(chǎng)景里（而上例僅是其中一種案例），需要解決的問(wèn)題本質(zhì)和庫(kù)存如何扣減沒(méi)有絲毫直接關(guān)系，其暴露的實(shí)質(zhì)問(wèn)題是如何實(shí)現(xiàn)一個(gè)分布式事務(wù)機(jī)制。這是一個(gè)比較大的專題，實(shí)現(xiàn)相對(duì)復(fù)雜，開(kāi)發(fā)成本也足夠高。基于單一RPC接口，到如今流行的更小粒度的微服務(wù)，都足夠?qū)懸槐緯恕＝刂鼓壳皞€(gè)人的了解，如早期的2PC （兩階段）、3PC（三階段）、TCC（補(bǔ)償事務(wù)），以及后來(lái)的純消息列表式方案等等，均是一些無(wú)法達(dá)到完美的理論（性能、時(shí)效、復(fù)雜度等）。至于實(shí)踐上，自然就沒(méi)有絕對(duì)OK的方案，只能根據(jù)項(xiàng)目規(guī)模和實(shí)際業(yè)務(wù)做些取舍，最終得到一個(gè)盡量滿足的“高可用”方案。以后待到經(jīng)驗(yàn)足夠，有機(jī)會(huì)嘗試一下單獨(dú)開(kāi)篇討論。（對(duì)于分布式事務(wù)，寫過(guò)一些demo，卻應(yīng)用不深，以后會(huì)考慮抽個(gè)專門的時(shí)間在續(xù)篇中嘗試撰寫探討）。? ? ? ? 六、結(jié)合高并發(fā)場(chǎng)景（如：秒殺活動(dòng)），簡(jiǎn)單聊聊如何關(guān)聯(lián)各類技術(shù)手段，進(jìn)行下單及庫(kù)存管控的應(yīng)用。 ? 在電商系統(tǒng)里，并發(fā)簡(jiǎn)直無(wú)處不在，目前較為突出的一個(gè)場(chǎng)景，則是秒殺活動(dòng)。所謂秒殺，最簡(jiǎn)單直觀的場(chǎng)景如下：在某個(gè)時(shí)刻，商品P開(kāi)放購(gòu)買（P的實(shí)際庫(kù)存僅為1個(gè)或者幾個(gè)），大批量的用戶同時(shí)進(jìn)行下單搶購(gòu)。 秒殺時(shí)并發(fā)量之大遠(yuǎn)遠(yuǎn)超過(guò)一般情況下的并發(fā)（你要考慮到不止一個(gè)商品），甚至還會(huì)影響到商城里現(xiàn)有其他業(yè)務(wù)（這里討論非獨(dú)立部署）。需要考慮諸多細(xì)節(jié)，以及大量技術(shù)手段來(lái)進(jìn)行有效管控。以下簡(jiǎn)單聊聊后臺(tái)下單相關(guān)問(wèn)題，不討論其他前端處理技術(shù)，包括定時(shí)查詢，頁(yè)面靜態(tài)化，網(wǎng)絡(luò)帶寬優(yōu)化等。 ? 6.1? 明確業(yè)務(wù)本質(zhì)需求，脫離業(yè)務(wù)，當(dāng)然談不了任何技術(shù)架構(gòu)和實(shí)現(xiàn)方案。 ? 　　秒殺的業(yè)務(wù)場(chǎng)景，宏觀上來(lái)說(shuō)，就是一個(gè)典型的排序模型。誰(shuí)先來(lái)，誰(shuí)先得到。這里我們盡量簡(jiǎn)化舉例：假定商品P庫(kù)存為10，同時(shí)參與下單的用戶數(shù)為100000。那么，最終只有開(kāi)始的（理論上的）10個(gè)用戶購(gòu)買成功，其余99990個(gè)用戶購(gòu)買失敗。商品庫(kù)存被成功消費(fèi)為0。 ? 6.2? 防作弊等安全監(jiān)測(cè)，從RPC的第一個(gè)接口開(kāi)始，就進(jìn)行過(guò)濾。 ? 　　例如，在雜記上一篇中提到的（見(jiàn)第一篇主題三），做好基礎(chǔ)的安全監(jiān)測(cè)機(jī)制。如相同IP的僵尸賬號(hào)，做限制IP的訪問(wèn)，并增加驗(yàn)證碼等。同時(shí)，包括但不限于一些額外的業(yè)務(wù)輔助手段，如限制僅滿足一定注冊(cè)時(shí)間的用戶可下單等。 ? 6.3? 限流機(jī)制，在外層計(jì)數(shù)，達(dá)到一個(gè)下單閾值，直接拋棄。 ? 　　從6.1中就可以發(fā)現(xiàn)，秒殺業(yè)務(wù)本身就注定了大部分人是搶不到的，那么針對(duì)大部分人的下單請(qǐng)求，完全就可以不做處理（直接拋棄）。在進(jìn)行真正的下單操作之前，可在具體操作接口上，增加一個(gè)攔截計(jì)數(shù)器來(lái)統(tǒng)計(jì)，比如當(dāng)計(jì)數(shù)超過(guò)3000時(shí)，后續(xù)下單直接返回?fù)屬?gòu)失敗的信息。這樣就將數(shù)據(jù)處理由大化小了，實(shí)現(xiàn)了限流（僅針對(duì)下單）。當(dāng)然，具體實(shí)現(xiàn)時(shí)，這個(gè)3000名額推薦是篩選后的。比如，先過(guò)濾8000，從中隨機(jī)抽取3000（這里不擴(kuò)展）。 ? 6.4? 從數(shù)據(jù)庫(kù)角度，首先就是要增加單獨(dú)的臨時(shí)緩存層。? ? 　　即使是3000的量，在這個(gè)環(huán)節(jié)也肯定是不能直接操作數(shù)據(jù)庫(kù)的（你要明白，實(shí)際秒殺的商品，不只一個(gè)），直接讀庫(kù)寫庫(kù)對(duì)數(shù)據(jù)庫(kù)壓力太大，甚至直接負(fù)載過(guò)大導(dǎo)致數(shù)據(jù)庫(kù)掛掉。那么，針對(duì)這種情況，推薦的一種方案就是結(jié)合緩存來(lái)操作。譬如：把商品P * 10 這條數(shù)據(jù)提前Push到專門的緩存中，然后每次讀取和更新，均是走的該緩存。這里額外提到一點(diǎn)，如果用戶下單成功，預(yù)扣庫(kù)存 -1，但又未進(jìn)行安全時(shí)間內(nèi)的支付，那么系統(tǒng)將自動(dòng)回滾商品P的庫(kù)存，進(jìn)行 +1（當(dāng)然，回滾同樣需要協(xié)調(diào)處理并發(fā)）。 ? 6.5? 從程序角度，修改庫(kù)存依然需要保證一定串行。 ? 　　首先，如果保證DAL的串行，可以是數(shù)據(jù)庫(kù)上鎖，也可以是程序上鎖（或者隊(duì)列）。但如果直接數(shù)據(jù)庫(kù)上鎖，諸多并發(fā)請(qǐng)求（依然考慮到，單時(shí)間內(nèi)的多個(gè)商品被多用戶搶購(gòu)），即使前面削減了部分下單處理，數(shù)據(jù)庫(kù)的I/O負(fù)載依然會(huì)很嚴(yán)重。那么，首先就是推薦樂(lè)觀進(jìn)隊(duì)列，然后悲觀進(jìn)分布式程序鎖，混合處理（即是對(duì)主題四的結(jié)合應(yīng)用）。 ? ? ? 結(jié)語(yǔ) ? 電商項(xiàng)目里，幾乎處處是并發(fā)，無(wú)論是單機(jī)還是分布式架構(gòu)。結(jié)合下單庫(kù)存管控相關(guān)，我們可以深刻理解解決這些并發(fā)性能問(wèn)題和并發(fā)安全顧慮，即使是同一類型的業(yè)務(wù)，也有諸多方案，每種方案都有一些細(xì)粒度的問(wèn)題需要嘗試克服，更需結(jié)合實(shí)際項(xiàng)目（具體業(yè)務(wù)性質(zhì)和規(guī)模），做一些實(shí)現(xiàn)上的各種優(yōu)化與權(quán)衡等。 ? ? [不知不覺(jué)又是凌晨?jī)牲c(diǎn)多了，本文作為系列第二篇雜記（部分延伸篇），暫告一段落吧。第三篇，待續(xù)。該睡了，晚安。] ? ? ? End. ? ? ? ?

轉(zhuǎn)載于:https://www.cnblogs.com/bsfz/p/7824428.html

總結(jié)

以上是生活随笔為你收集整理的[原创]商城系统下单库存管控系列杂记（二）（并发安全和性能部分延伸）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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