：從0到1的保姆級教程)
lol道聚城項目實戰(zhàn)：從0到1的保姆級教程
是不是剛學完P(guān)ython或Java基礎(chǔ)，對著空白的編輯器發(fā)呆？知道for循環(huán)怎么寫，知道類怎么繼承，但一旦要做一個像樣點的項目，腦子就一片空白。這種“手殘”感太常見了。今天這篇保姆級教程，我們不講虛的，直接拿lol道聚城這個經(jīng)典電商案例開刀。我們要把底層原理拆碎了揉進代碼里，讓你明白一個高并發(fā)商城是怎么跑起來的。別被名字嚇到，核心邏輯就是“商品展示+購物車+下單支付”，把這套流程吃透，面試時你就有底氣說“我做過項目”。
一句話原理：高并發(fā)下的庫存扣減與狀態(tài)流轉(zhuǎn)
在lol道聚城這類系統(tǒng)中，最核心的痛點不是怎么把皮膚圖顯示出來，而是高并發(fā)下的庫存一致性。想象一下，S級皮膚“至臻系列”上架瞬間，幾萬人同時點擊購買。如果代碼寫得不好，就會出現(xiàn)“超賣”（賣了100件，庫存只有80件）或者“少賣”（有人付款成功，但訂單狀態(tài)卡在初始化）。
底層原理其實很簡單：CAS（Compare-And-Swap）原子操作配合分布式鎖或Redis預(yù)扣減。數(shù)據(jù)庫直接扣減太慢，必須把熱點數(shù)據(jù)搬到內(nèi)存（Redis），在內(nèi)存里做快速判斷和扣減，然后再異步同步到MySQL數(shù)據(jù)庫。這就是為什么電商架構(gòu)里，Redis的地位舉足輕重。
類比解釋：超市收銀臺與貨架模型
為了讓你秒懂，我們用一個線下超市的類比。
假設(shè)lol道聚城的服務(wù)器是一個大型超市。MySQL數(shù)據(jù)庫是倉庫深處的貨架。每次去倉庫拿貨，都要走很遠的路，而且倉庫管理員（DBA）很謹慎，每次只能處理一單，速度極慢。
Redis緩存是收銀臺旁邊的展示柜。商品就擺在手邊，伸手就能拿，速度極快。普通寫法（直接操作MySQL）：
用戶點擊購買 - 請求到達收銀臺 - 收銀員跑去倉庫查庫存 - 確認有貨 - 跑去倉庫扣減庫存 - 回來告訴用戶成功。
如果100個人同時買同一款皮膚，收銀員就得跑100趟倉庫。倉庫門口堵死，系統(tǒng)崩潰。
高并發(fā)寫法（Redis預(yù)扣減）：
用戶點擊購買 - 請求到達收銀臺 - 收銀員先看展示柜（Redis）有沒有貨 - 如果有，直接在展示柜劃掉一件（原子操作） - 告訴用戶“扣減成功，正在后臺處理” - 后臺線程慢慢去倉庫（MySQL）同步數(shù)據(jù)。
這樣，收銀臺的壓力被分散了，倉庫也不會瞬間擁堵。這就是lol道聚城項目中最經(jīng)典的緩存穿透、擊穿、雪崩防護機制的實際應(yīng)用場景。
源碼/偽代碼片段：Redis原子扣減的核心邏輯
很多初學者以為扣減庫存就是stock - 1，這在Java里是非原子操作。在多線程環(huán)境下，兩個線程同時讀到stock=1，同時執(zhí)行減1，結(jié)果都寫回0，但實際賣出了2件。
下面是一段基于Java + Redisson（Redis客戶端框架）的lol道聚城庫存扣減核心邏輯偽代碼。注意看compareAndSet和Lua腳本的原子性保證。
/*** lol道聚城 核心庫存服務(wù)類* 技術(shù)棧: Spring Boot + Redisson + MySQL*/
@Service
public class InventoryService {@Autowiredprivate RedissonClient redissonClient;/*** 嘗試扣減庫存* @param itemId 商品ID (例如: lol-skin-10086)* @param amount 扣減數(shù)量* @return true: 扣減成功; false: 庫存不足*/public boolean tryDeductStock(Long itemId, int amount) {String stockKey = lol_daoju_city:stock: + itemId;// 1. 獲取分布式鎖，防止同一用戶并發(fā)重復(fù)下單（可選，通常結(jié)合業(yè)務(wù)ID做冪等）// 這里我們演示更底層的Lua原子扣減，性能優(yōu)于加鎖// 2. 使用Lua腳本保證“判斷”和“扣減”的原子性String luaScript = local stock = tonumber(redis.call('get', KEYS[1])) +if (stock ~= nil) and (stock = tonumber(ARGV[1])) then + redis.call('decrby', KEYS[1], ARGV[1]) + return 1 +else + return 0 +end;RScript script = redissonClient.getScript();// 3. 執(zhí)行腳本// KEYS[1]: 商品庫存Key// ARGV[1]: 需要扣減的數(shù)量Long result = script.eval(RScript.Mode.READ_WRITE, luaScript, RScript.ReturnType.INTEGER, Collections.singletonList(stockKey), amount);// 4. 判斷結(jié)果return result != null result == 1L;}/*** 初始化庫存（商品上架時調(diào)用）*/public void initStock(Long itemId, int initialStock) {String stockKey = lol_daoju_city:stock: + itemId;// 設(shè)置過期時間，防止死數(shù)據(jù)，比如24小時未售出自動清理緩存redissonClient.getBucket(stockKey).set(initialStock, 24, TimeUnit.HOURS);}
}逐行講解關(guān)鍵點：redis.call('get', KEYS[1]): 在Redis服務(wù)端獲取當前庫存。
if (stock = tonumber(ARGV[1])): 在內(nèi)存中判斷庫存是否足夠。這一步避免了頻繁訪問數(shù)據(jù)庫。
redis.call('decrby', KEYS[1], ARGV[1]): 如果足夠，直接原子性地減少庫存。Redis的decrby命令本身是原子的，不會丟失更新。
為什么不用if-else在Java代碼里寫？ 因為Java的if判斷和Redis的decrby是兩次網(wǎng)絡(luò)往返。在兩次操作之間，其他線程可能已經(jīng)扣減了庫存，導致超賣。Lua腳本讓Redis把這些指令打包成一個整體執(zhí)行，中間不會有其他命令插入。流程描述：從點擊購買到支付成功的完整鏈路
理解了原子扣減，我們來看lol道局城整個交易的全景流程圖。這是一個典型的最終一致性方案。用戶請求：用戶在網(wǎng)頁點擊“立即購買”，前端發(fā)送POST請求到API網(wǎng)關(guān)。
參數(shù)校驗與冪等性檢查：網(wǎng)關(guān)層校驗Token，并檢查訂單號是否已存在（防止用戶手抖雙擊提交）。
預(yù)扣減庫存：調(diào)用上述tryDeductStock方法。如果返回false，直接返回前端“庫存不足”，流程結(jié)束。
如果返回true，繼續(xù)下一步。創(chuàng)建訂單：在MySQL中創(chuàng)建一條狀態(tài)為WAIT_PAY（待支付）的訂單記錄。此時不扣減MySQL庫存，只記錄訂單快照（價格、商品ID、用戶ID）。
發(fā)送MQ消息：將訂單信息發(fā)送到消息隊列（如RabbitMQ或Kafka），Topic為order-created。
異步處理：服務(wù)A（庫存同步服務(wù)）：消費order-created消息，真正去MySQL執(zhí)行UPDATE stock SET count = count - 1 WHERE id = ?。如果MySQL扣減失?。ū热鐜齑嬲娴臎]了），則觸發(fā)補償機制。
服務(wù)B（通知服務(wù)）：消費消息，發(fā)送短信或站內(nèi)信通知用戶。支付回調(diào)：用戶支付成功，第三方支付平臺（如支付寶）回調(diào)通知。
訂單狀態(tài)更新：將MySQL訂單狀態(tài)改為PAID（已支付）。
發(fā)貨/發(fā)卡：如果是虛擬商品（lol皮膚），直接發(fā)放到賬號郵箱或客戶端；如果是實物，生成物流單。關(guān)鍵細節(jié)：為什么第4步不直接扣MySQL？
因為MySQL的寫性能遠低于Redis。如果在高并發(fā)下，10萬個請求都走到MySQL去扣庫存，數(shù)據(jù)庫連接池會瞬間耗盡。通過Redis預(yù)扣減，我們可以攔截掉99%的無效請求（庫存不足的請求），只有真正扣減成功的少量請求才會進入數(shù)據(jù)庫。
實戰(zhàn)驗證：如何避免“超賣”與“少賣”
在lol道局城的實際開發(fā)中，光有Redis扣減還不夠，必須處理異常場景。
場景一：Redis扣減成功，但MySQL寫入失?。ňW(wǎng)絡(luò)抖動）后果：用戶以為買到了，但訂單沒生成，或者訂單生成了但庫存沒扣。
解決方案：引入事務(wù)消息或本地消息表。在創(chuàng)建訂單時，先在MySQL事務(wù)里插入訂單（狀態(tài)INIT）和一條消息記錄（狀態(tài)PENDING）。
事務(wù)提交后，發(fā)送MQ消息。
如果MQ發(fā)送失敗，定時任務(wù)掃描PENDING狀態(tài)的消息進行重發(fā)。
保證“訂單創(chuàng)建”和“消息發(fā)送”的原子性。場景二：支付超時，訂單取消后果：Redis里的庫存被預(yù)扣減了，但用戶沒付款，庫存被“鎖定”了。
解決方案：延遲隊列。下單時，向MQ發(fā)送一條延遲30分鐘的消息。
30分鐘后，消費者檢查訂單狀態(tài)。如果仍是WAIT_PAY，則取消訂單，并調(diào)用addStock方法，將Redis和MySQL的庫存加回去。
這里要注意，回補庫存也要考慮并發(fā)，最好也用Lua腳本或incrby原子操作。Stack Overflow上的經(jīng)典爭議：
在Stack Overflow上，關(guān)于“Redis扣減后MySQL回滾”的問題討論極多。很多開發(fā)者初期喜歡用try-catch包裹MySQL操作，如果失敗就redis.incr回補。但這有個隱患：如果程序在redis.decr和mysql.update之間崩潰（比如服務(wù)器斷電），庫存就永久丟失了。
更穩(wěn)健的做法是：以MySQL為準，Redis只是加速層。Redis扣減成功。
發(fā)MQ消息。
消費者去MySQL扣減。
如果MySQL扣減失敗，不直接回補Redis，而是記錄一條“異常流水”。
后臺定時任務(wù)對比Redis庫存和MySQL庫存，發(fā)現(xiàn)不一致時，以MySQL為準修正Redis，并報警。
這種“最終一致性”方案在金融級和電商級項目中更為常見，因為它能容忍短暫的不一致，但能保證數(shù)據(jù)最終準確。進階技巧與避坑指南緩存預(yù)熱：
lol道局城在皮膚上新前，必須提前將庫存加載到Redis。如果冷啟動，第一個請求可能穿透到MySQL，導致緩存擊穿。可以在應(yīng)用啟動時，或者通過定時任務(wù)，將熱銷商品庫存同步到Redis。熱點Key檢測：
如果某個S級皮膚特別火，Redis的單線程可能成為瓶頸。可以使用本地緩存（Caffeine） + Redis的兩級緩存結(jié)構(gòu)。本地緩存負責擋住99%的讀請求，Redis負責寫操作和全局一致性。前端防抖與限流：
在lol道局城的前端代碼中，按鈕點擊后要立即置灰，防止用戶狂點。同時，網(wǎng)關(guān)層（Nginx或Sentinel）要配置限流規(guī)則，比如每個IP每秒最多10次請求。數(shù)據(jù)一致性監(jiān)控：
寫一個簡單的腳本，每5分鐘比對一次Redis和MySQL的庫存。如果差異超過閾值（比如5件），立即告警。這是線上運維的保命符。面試高頻問題預(yù)警：
面試官很可能會問：“你的lol道局城項目里，Redis和MySQL數(shù)據(jù)不一致怎么辦？”
如果你能答出：“采用最終一致性方案，通過MQ異步同步，結(jié)合定時任務(wù)比對修正，并設(shè)置告警機制”，這比背誦八股文要有說服力得多。
這個知識點你面試被問過嗎？留言說說 lol道聚城項目實戰(zhàn)：從0到1的保姆級教程
lol道聚城項目實戰(zhàn)：從0到1的保姆級教程
是不是剛學完P(guān)ython或Java基礎(chǔ)，對著空白的編輯器發(fā)呆？知道for循環(huán)怎么寫，知道類怎么繼承，但一旦要做一個像樣點的項目，腦子就一片空白。這種“手殘”感太常見了。今天這篇保姆級教程，我們不講虛的，直接拿lol道聚城這個經(jīng)典電商案例開刀。我們要把底層原理拆碎了揉進代碼里，讓你明白一個高并發(fā)商城是怎么跑起來的。別被名字嚇到，核心邏輯就是“商品展示+購物車+下單支付”，把這套流程吃透，面試時你就有底氣說“我做過項目”。
一句話原理：高并發(fā)下的庫存扣減與狀態(tài)流轉(zhuǎn)
在lol道聚城這類系統(tǒng)中，最核心的痛點不是怎么把皮膚圖顯示出來，而是高并發(fā)下的庫存一致性。想象一下，S級皮膚“至臻系列”上架瞬間，幾萬人同時點擊購買。如果代碼寫得不好，就會出現(xiàn)“超賣”（賣了100件，庫存只有80件）或者“少賣”（有人付款成功，但訂單狀態(tài)卡在初始化）。
底層原理其實很簡單：CAS（Compare-And-Swap）原子操作配合分布式鎖或Redis預(yù)扣減。數(shù)據(jù)庫直接扣減太慢，必須把熱點數(shù)據(jù)搬到內(nèi)存（Redis），在內(nèi)存里做快速判斷和扣減，然后再異步同步到MySQL數(shù)據(jù)庫。這就是為什么電商架構(gòu)里，Redis的地位舉足輕重。
類比解釋：超市收銀臺與貨架模型
為了讓你秒懂，我們用一個線下超市的類比。
假設(shè)lol道聚城的服務(wù)器是一個大型超市。MySQL數(shù)據(jù)庫是倉庫深處的貨架。每次去倉庫拿貨，都要走很遠的路，而且倉庫管理員（DBA）很謹慎，每次只能處理一單，速度極慢。
Redis緩存是收銀臺旁邊的展示柜。商品就擺在手邊，伸手就能拿，速度極快。普通寫法（直接操作MySQL）：
用戶點擊購買 - 請求到達收銀臺 - 收銀員跑去倉庫查庫存 - 確認有貨 - 跑去倉庫扣減庫存 - 回來告訴用戶成功。
如果100個人同時買同一款皮膚，收銀員就得跑100趟倉庫。倉庫門口堵死，系統(tǒng)崩潰。
高并發(fā)寫法（Redis預(yù)扣減）：
用戶點擊購買 - 請求到達收銀臺 - 收銀員先看展示柜（Redis）有沒有貨 - 如果有，直接在展示柜劃掉一件（原子操作） - 告訴用戶“扣減成功，正在后臺處理” - 后臺線程慢慢去倉庫（MySQL）同步數(shù)據(jù)。
這樣，收銀臺的壓力被分散了，倉庫也不會瞬間擁堵。這就是lol道聚城項目中最經(jīng)典的緩存穿透、擊穿、雪崩防護機制的實際應(yīng)用場景。
源碼/偽代碼片段：Redis原子扣減的核心邏輯
很多初學者以為扣減庫存就是stock - 1，這在Java里是非原子操作。在多線程環(huán)境下，兩個線程同時讀到stock=1，同時執(zhí)行減1，結(jié)果都寫回0，但實際賣出了2件。
下面是一段基于Java + Redisson（Redis客戶端框架）的lol道聚城庫存扣減核心邏輯偽代碼。注意看compareAndSet和Lua腳本的原子性保證。
/*** lol道聚城 核心庫存服務(wù)類* 技術(shù)棧: Spring Boot + Redisson + MySQL*/
@Service
public class InventoryService {@Autowiredprivate RedissonClient redissonClient;/*** 嘗試扣減庫存* @param itemId 商品ID (例如: lol-skin-10086)* @param amount 扣減數(shù)量* @return true: 扣減成功; false: 庫存不足*/public boolean tryDeductStock(Long itemId, int amount) {String stockKey = lol_daoju_city:stock: + itemId;// 1. 獲取分布式鎖，防止同一用戶并發(fā)重復(fù)下單（可選，通常結(jié)合業(yè)務(wù)ID做冪等）// 這里我們演示更底層的Lua原子扣減，性能優(yōu)于加鎖// 2. 使用Lua腳本保證“判斷”和“扣減”的原子性String luaScript = local stock = tonumber(redis.call('get', KEYS[1])) +if (stock ~= nil) and (stock = tonumber(ARGV[1])) then + redis.call('decrby', KEYS[1], ARGV[1]) + return 1 +else + return 0 +end;RScript script = redissonClient.getScript();// 3. 執(zhí)行腳本// KEYS[1]: 商品庫存Key// ARGV[1]: 需要扣減的數(shù)量Long result = script.eval(RScript.Mode.READ_WRITE, luaScript, RScript.ReturnType.INTEGER, Collections.singletonList(stockKey), amount);// 4. 判斷結(jié)果return result != null result == 1L;}/*** 初始化庫存（商品上架時調(diào)用）*/public void initStock(Long itemId, int initialStock) {String stockKey = lol_daoju_city:stock: + itemId;// 設(shè)置過期時間，防止死數(shù)據(jù)，比如24小時未售出自動清理緩存redissonClient.getBucket(stockKey).set(initialStock, 24, TimeUnit.HOURS);}
}逐行講解關(guān)鍵點：redis.call('get', KEYS[1]): 在Redis服務(wù)端獲取當前庫存。
if (stock = tonumber(ARGV[1])): 在內(nèi)存中判斷庫存是否足夠。這一步避免了頻繁訪問數(shù)據(jù)庫。
redis.call('decrby', KEYS[1], ARGV[1]): 如果足夠，直接原子性地減少庫存。Redis的decrby命令本身是原子的，不會丟失更新。
為什么不用if-else在Java代碼里寫？ 因為Java的if判斷和Redis的decrby是兩次網(wǎng)絡(luò)往返。在兩次操作之間，其他線程可能已經(jīng)扣減了庫存，導致超賣。Lua腳本讓Redis把這些指令打包成一個整體執(zhí)行，中間不會有其他命令插入。流程描述：從點擊購買到支付成功的完整鏈路
理解了原子扣減，我們來看lol道局城整個交易的全景流程圖。這是一個典型的最終一致性方案。用戶請求：用戶在網(wǎng)頁點擊“立即購買”，前端發(fā)送POST請求到API網(wǎng)關(guān)。
參數(shù)校驗與冪等性檢查：網(wǎng)關(guān)層校驗Token，并檢查訂單號是否已存在（防止用戶手抖雙擊提交）。
預(yù)扣減庫存：調(diào)用上述tryDeductStock方法。如果返回false，直接返回前端“庫存不足”，流程結(jié)束。
如果返回true，繼續(xù)下一步。創(chuàng)建訂單：在MySQL中創(chuàng)建一條狀態(tài)為WAIT_PAY（待支付）的訂單記錄。此時不扣減MySQL庫存，只記錄訂單快照（價格、商品ID、用戶ID）。
發(fā)送MQ消息：將訂單信息發(fā)送到消息隊列（如RabbitMQ或Kafka），Topic為order-created。
異步處理：服務(wù)A（庫存同步服務(wù)）：消費order-created消息，真正去MySQL執(zhí)行UPDATE stock SET count = count - 1 WHERE id = ?。如果MySQL扣減失?。ū热鐜齑嬲娴臎]了），則觸發(fā)補償機制。
服務(wù)B（通知服務(wù)）：消費消息，發(fā)送短信或站內(nèi)信通知用戶。支付回調(diào)：用戶支付成功，第三方支付平臺（如支付寶）回調(diào)通知。
訂單狀態(tài)更新：將MySQL訂單狀態(tài)改為PAID（已支付）。
發(fā)貨/發(fā)卡：如果是虛擬商品（lol皮膚），直接發(fā)放到賬號郵箱或客戶端；如果是實物，生成物流單。關(guān)鍵細節(jié)：為什么第4步不直接扣MySQL？
因為MySQL的寫性能遠低于Redis。如果在高并發(fā)下，10萬個請求都走到MySQL去扣庫存，數(shù)據(jù)庫連接池會瞬間耗盡。通過Redis預(yù)扣減，我們可以攔截掉99%的無效請求（庫存不足的請求），只有真正扣減成功的少量請求才會進入數(shù)據(jù)庫。
實戰(zhàn)驗證：如何避免“超賣”與“少賣”
在lol道局城的實際開發(fā)中，光有Redis扣減還不夠，必須處理異常場景。
場景一：Redis扣減成功，但MySQL寫入失?。ňW(wǎng)絡(luò)抖動）后果：用戶以為買到了，但訂單沒生成，或者訂單生成了但庫存沒扣。
解決方案：引入事務(wù)消息或本地消息表。在創(chuàng)建訂單時，先在MySQL事務(wù)里插入訂單（狀態(tài)INIT）和一條消息記錄（狀態(tài)PENDING）。
事務(wù)提交后，發(fā)送MQ消息。
如果MQ發(fā)送失敗，定時任務(wù)掃描PENDING狀態(tài)的消息進行重發(fā)。
保證“訂單創(chuàng)建”和“消息發(fā)送”的原子性。場景二：支付超時，訂單取消后果：Redis里的庫存被預(yù)扣減了，但用戶沒付款，庫存被“鎖定”了。
解決方案：延遲隊列。下單時，向MQ發(fā)送一條延遲30分鐘的消息。
30分鐘后，消費者檢查訂單狀態(tài)。如果仍是WAIT_PAY，則取消訂單，并調(diào)用addStock方法，將Redis和MySQL的庫存加回去。
這里要注意，回補庫存也要考慮并發(fā)，最好也用Lua腳本或incrby原子操作。Stack Overflow上的經(jīng)典爭議：
在Stack Overflow上，關(guān)于“Redis扣減后MySQL回滾”的問題討論極多。很多開發(fā)者初期喜歡用try-catch包裹MySQL操作，如果失敗就redis.incr回補。但這有個隱患：如果程序在redis.decr和mysql.update之間崩潰（比如服務(wù)器斷電），庫存就永久丟失了。
更穩(wěn)健的做法是：以MySQL為準，Redis只是加速層。Redis扣減成功。
發(fā)MQ消息。
消費者去MySQL扣減。
如果MySQL扣減失敗，不直接回補Redis，而是記錄一條“異常流水”。
后臺定時任務(wù)對比Redis庫存和MySQL庫存，發(fā)現(xiàn)不一致時，以MySQL為準修正Redis，并報警。
這種“最終一致性”方案在金融級和電商級項目中更為常見，因為它能容忍短暫的不一致，但能保證數(shù)據(jù)最終準確。進階技巧與避坑指南緩存預(yù)熱：
lol道局城在皮膚上新前，必須提前將庫存加載到Redis。如果冷啟動，第一個請求可能穿透到MySQL，導致緩存擊穿。可以在應(yīng)用啟動時，或者通過定時任務(wù)，將熱銷商品庫存同步到Redis。熱點Key檢測：
如果某個S級皮膚特別火，Redis的單線程可能成為瓶頸。可以使用本地緩存（Caffeine） + Redis的兩級緩存結(jié)構(gòu)。本地緩存負責擋住99%的讀請求，Redis負責寫操作和全局一致性。前端防抖與限流：
在lol道局城的前端代碼中，按鈕點擊后要立即置灰，防止用戶狂點。同時，網(wǎng)關(guān)層（Nginx或Sentinel）要配置限流規(guī)則，比如每個IP每秒最多10次請求。數(shù)據(jù)一致性監(jiān)控：
寫一個簡單的腳本，每5分鐘比對一次Redis和MySQL的庫存。如果差異超過閾值（比如5件），立即告警。這是線上運維的保命符。面試高頻問題預(yù)警：
面試官很可能會問：“你的lol道局城項目里，Redis和MySQL數(shù)據(jù)不一致怎么辦？”
如果你能答出：“采用最終一致性方案，通過MQ異步同步，結(jié)合定時任務(wù)比對修正，并設(shè)置告警機制”，這比背誦八股文要有說服力得多。
這個知識點你面試被問過嗎？留言說說