拆解:3個(gè)面試必問核心點(diǎn)與代碼實(shí)戰(zhàn))
在行app架構(gòu)拆解:3個(gè)面試必問核心點(diǎn)與代碼實(shí)戰(zhàn)
官方文檔堆砌著數(shù)百頁的API說明，翻得人頭大卻抓不住重點(diǎn)，這種痛苦每個(gè)搞技術(shù)的都懂。但當(dāng)你把視線從枯燥的文字移開，聚焦到“在行app”這個(gè)具體產(chǎn)品時(shí)，面試必問的那些高頻考點(diǎn)瞬間就活了。
別被名字誤導(dǎo)，“在行app”在這里并非指代某個(gè)特定的社交軟件，而是我們在面試突擊中構(gòu)建的一個(gè)典型高并發(fā)專家咨詢平臺模型。為什么選它？因?yàn)樗臉I(yè)務(wù)場景——用戶提問、專家接單、即時(shí)溝通、異步交付——完美覆蓋了后端開發(fā)中狀態(tài)機(jī)管理、分布式鎖、消息隊(duì)列削峰這三大面試必問的硬核考點(diǎn)。
今天這篇，不整虛的，直接對著這個(gè)模型拆解。我們將按照【對比式結(jié)構(gòu)】，把常見的錯(cuò)誤答法與標(biāo)準(zhǔn)答法做對比，用代碼把原理釘死，最后給你一套記憶口訣，讓你下次被問到類似問題時(shí)，能像老手一樣從容應(yīng)對。
考點(diǎn)梳理:為什么面試官愛問“在行”場景
很多候選人一聽到“設(shè)計(jì)一個(gè)咨詢系統(tǒng)”，腦子里全是CRUD，這是大忌。面試官問“在行app”這類場景，核心考點(diǎn)其實(shí)只有三個(gè)維度：訂單狀態(tài)的一致性：從“待接單”到“已交付”，中間涉及多角色操作，如何防止?fàn)顟B(tài)錯(cuò)亂？
高并發(fā)下的資源競爭：熱門專家同時(shí)被100人搶單，如何保證不超賣？
異步交互的可靠性：消息發(fā)送了但對方?jīng)]收到，或者專家回復(fù)了但用戶端沒刷新，怎么保證最終一致性？錯(cuò)誤認(rèn)知對比：初級答法：用數(shù)據(jù)庫事務(wù)包裹整個(gè)流程，加行鎖解決并發(fā)。后果：數(shù)據(jù)庫連接池瞬間打滿，系統(tǒng)直接崩盤，這在面試中屬于“一票否決”。高級答法：引入Redis做預(yù)扣減，MQ做異步解耦，數(shù)據(jù)庫只做最終落庫。后果：抗壓能力強(qiáng)，架構(gòu)清晰，這才是大廠想聽的。記住，面試官問的不是“怎么做”，而是“為什么這么做”以及“這么做的代價(jià)是什么”。
標(biāo)準(zhǔn)答法:構(gòu)建狀態(tài)機(jī)與并發(fā)控制模型
在“在行app”模型中，最核心的實(shí)體是ConsultOrder（咨詢訂單）。一個(gè)標(biāo)準(zhǔn)的訂單生命周期如下：
CREATED (已創(chuàng)建) - ACCEPTED (專家已接單) - IN_PROGRESS (咨詢中) - FINISHED (已完成) - EVALUATED (已評價(jià))
這里有兩個(gè)面試必問的深水區(qū)：
1. 狀態(tài)流轉(zhuǎn)的合法性校驗(yàn)
你不能直接從CREATED跳到FINISHED。面試中，要強(qiáng)調(diào)使用**狀態(tài)機(jī)模式（State Machine Pattern）**來管理。不要在業(yè)務(wù)代碼里寫滿if (status == 1) { ... }，那樣代碼維護(hù)起來是噩夢。
2. 搶單場景的分布式鎖
假設(shè)專家A有10個(gè)咨詢名額，瞬間來了100個(gè)請求。方案A：數(shù)據(jù)庫樂觀鎖。update orders set status=1 where status=0 and expert_id=1 limit 1。缺點(diǎn)：數(shù)據(jù)庫壓力大，且在高并發(fā)下性能瓶頸明顯。方案B：Redis分布式鎖 + Lua腳本。優(yōu)點(diǎn)：原子性強(qiáng)，性能高，是主流互聯(lián)網(wǎng)公司的標(biāo)準(zhǔn)答案。標(biāo)準(zhǔn)話術(shù)模板：
“在處理‘在行app’這類高并發(fā)咨詢平臺時(shí)，我會(huì)將訂單狀態(tài)管理與資源搶占分離。對于狀態(tài)流轉(zhuǎn)，采用狀態(tài)機(jī)模式確保邏輯嚴(yán)密；對于專家名額的搶占，采用Redis原子操作進(jìn)行預(yù)扣減，通過Lua腳本保證檢查與扣減的原子性，最后通過MQ異步通知數(shù)據(jù)庫持久化，以解決高并發(fā)下的性能與一致性問題?！?代碼實(shí)現(xiàn):Redis Lua腳本解決超賣問題
光說不練假把式。面試中如果允許白板編程或手撕代碼，這一段就是你的得分點(diǎn)。以下是基于Redis的Lua腳本，用于解決“專家咨詢名額”的超賣問題。
-- KEYS[1]: expert_quota_key (專家剩余名額Key, 例如: expert:quota:1001)
-- KEYS[2]: order_lock_key (訂單創(chuàng)建鎖Key, 防止同一用戶重復(fù)提交)
-- ARGV[1]: user_id (當(dāng)前請求的用戶ID)
-- ARGV[2]: expire_time (鎖的過期時(shí)間，秒)-- 1. 檢查用戶是否已經(jīng)持有鎖，防止重復(fù)提交
if redis.call(exists, KEYS[2] .. : .. ARGV[1]) == 1 thenreturn USER_LOCKED
end-- 2. 檢查專家剩余名額
local remaining = tonumber(redis.call(get, KEYS[1]))
if remaining == nil thenreturn KEY_NOT_FOUND
endif remaining = 0 thenreturn NO_QUOTA
end-- 3. 原子扣減名額
redis.call(decr, KEYS[1])-- 4. 設(shè)置用戶鎖，防止短時(shí)間內(nèi)的重復(fù)請求
-- 使用setex確保鎖的原子性設(shè)置
redis.call(setex, KEYS[2] .. : .. ARGV[1], ARGV[2], 1)return SUCCESS代碼逐行解析（面試加分項(xiàng)）：防重邏輯：KEYS[2] .. : .. ARGV[1] 構(gòu)造了以用戶ID為后綴的鎖Key。如果一個(gè)用戶手抖點(diǎn)了兩次“咨詢”，第二次請求進(jìn)來時(shí)，exists檢查會(huì)發(fā)現(xiàn)鎖已存在，直接返回USER_LOCKED。這比單純扣減名額更嚴(yán)謹(jǐn)，因?yàn)樗谌肟谔幘蛿r截了無效請求。
原子性保障：Lua腳本在Redis中是原子執(zhí)行的。從get到decr再到setex，中間不會(huì)插入其他客戶端的操作。這就避免了經(jīng)典的“檢查-執(zhí)行”競態(tài)條件（Race Condition）。
返回碼設(shè)計(jì)：返回字符串而非數(shù)字，便于Java/Go端直接映射為枚舉狀態(tài)，減少類型轉(zhuǎn)換開銷。Java端調(diào)用示例（偽代碼）：
public String tryAcquireQuota(String expertId, String userId) {String quotaKey = expert:quota: + expertId;String lockKey = order:lock: + expertId;// 定義Lua腳本String script = if redis.call('exists', KEYS[2] .. ':' .. ARGV[1]) == 1 then return 'USER_LOCKED' end +local remaining = tonumber(redis.call('get', KEYS[1])) +if remaining == nil then return 'KEY_NOT_FOUND' end +if remaining = 0 then return 'NO_QUOTA' end +redis.call('decr', KEYS[1]) +redis.call('setex', KEYS[2] .. ':' .. ARGV[1], ARGV[2], '1') +return 'SUCCESS';Object result = redisTemplate.execute(new DefaultRedisScript(script, String.class),Arrays.asList(quotaKey, lockKey),userId,30 // 鎖過期時(shí)間30秒);return (String) result;
}追問與延伸:當(dāng)Redis掛了怎么辦？
面試官聽到這里，通常會(huì)追問：“如果Redis節(jié)點(diǎn)宕機(jī)，或者網(wǎng)絡(luò)分區(qū)導(dǎo)致Lua腳本執(zhí)行了一半失敗，數(shù)據(jù)不一致怎么辦？”
這是區(qū)分中級和高級的關(guān)鍵點(diǎn)。你需要展示對最終一致性的理解。
標(biāo)準(zhǔn)應(yīng)對策略：Redis數(shù)據(jù)持久化：強(qiáng)調(diào)Redis開啟了AOF（Append Only File）持久化，且策略為everysec，最多丟失1秒數(shù)據(jù)。對于咨詢訂單這種非資金類場景，1秒的誤差是可接受的。
數(shù)據(jù)庫兜底校驗(yàn)：Redis只是“預(yù)扣減”。當(dāng)用戶真正下單時(shí)，Java服務(wù)會(huì)向MySQL發(fā)起請求。SQL語句中包含狀態(tài)檢查：
UPDATE consult_order
SET status = 'ACCEPTED', expert_id = #{expertId}
WHERE id = #{orderId} AND status = 'CREATED';如果影響行數(shù)為0，說明狀態(tài)已變或訂單不存在，此時(shí)需要觸發(fā)補(bǔ)償機(jī)制。
對賬任務(wù)：定時(shí)任務(wù)掃描Redis中的剩余名額與數(shù)據(jù)庫中的實(shí)際占用情況。如果Redis顯示有名額但數(shù)據(jù)庫里沒有對應(yīng)訂單，說明數(shù)據(jù)漂移，觸發(fā)告警并人工介入或自動(dòng)修正。延伸考點(diǎn)：消息隊(duì)列的作用
在Redis扣減成功后，不要直接同步寫數(shù)據(jù)庫。應(yīng)該發(fā)送一條OrderCreated消息到Kafka或RocketMQ。好處1：削峰填谷。數(shù)據(jù)庫壓力被平滑。
好處2：解耦。通知服務(wù)、短信服務(wù)、專家端App推送服務(wù)都監(jiān)聽這條消息，各自處理，互不阻塞。
好處3：事務(wù)消息。利用RocketMQ的事務(wù)消息機(jī)制，確?！癛edis扣減”與“MQ消息發(fā)送”的邏輯一致性。如果Redis扣減成功但MQ發(fā)送失敗，可以通過本地事務(wù)表或死信隊(duì)列進(jìn)行重試。記憶口訣:狀態(tài)鎖隊(duì)兜底
為了讓你在面試緊張時(shí)能瞬間回憶起這套組合拳，送你一個(gè)口訣：
“狀態(tài)機(jī)管流轉(zhuǎn)，Redis鎖防超賣，Lua原子扣名額，MQ異步解耦壓，數(shù)據(jù)庫兜底查，對賬任務(wù)保無差?！睜顟B(tài)機(jī)管流轉(zhuǎn)：別用if-else，用狀態(tài)機(jī)。
Redis鎖防超賣：高并發(fā)先想Redis。
Lua原子扣名額：檢查+扣減要原子。
MQ異步解耦壓：別同步寫庫，要發(fā)消息。
數(shù)據(jù)庫兜底查：SQL里加狀態(tài)條件，防并發(fā)錯(cuò)亂。
對賬任務(wù)保無差：最終一致性靠對賬。最后，關(guān)于“在行app”這個(gè)模型，還有一個(gè)容易被忽略的細(xì)節(jié)：超時(shí)取消機(jī)制。
如果專家接單后長時(shí)間不回復(fù)，或者用戶支付后專家未開始咨詢，訂單需要自動(dòng)回滾。這需要用到延遲隊(duì)列。在Redis中可以使用ZSET（有序集合）實(shí)現(xiàn)，Score為執(zhí)行時(shí)間戳，消費(fèi)者輪詢到期Key并執(zhí)行取消邏輯。或者直接使用RocketMQ的延遲消息功能，發(fā)送一條延遲15分鐘的OrderTimeout消息。
避坑指南：
千萬不要在代碼里用Thread.sleep或者Timer來實(shí)現(xiàn)延遲取消，這在分布式環(huán)境下是完全不可靠的。必須依賴中間件的消息調(diào)度能力。
實(shí)戰(zhàn)建議：
在準(zhǔn)備面試時(shí)，不要只背概念。建議你畫一張架構(gòu)圖，把“在行app”的請求鏈路畫出來：用戶端 - API網(wǎng)關(guān) - 訂單服務(wù)(Redis+Lua) - MQ - 數(shù)據(jù)庫/通知服務(wù)。對著圖講，邏輯最清晰。
你公司項(xiàng)目里是怎么處理高并發(fā)搶單或資源鎖定的？是用的Redis還是數(shù)據(jù)庫？歡迎評論分享你的實(shí)戰(zhàn)經(jīng)驗(yàn)，我們一起避坑。 在行app架構(gòu)拆解:3個(gè)面試必問核心點(diǎn)與代碼實(shí)戰(zhàn)
在行app架構(gòu)拆解:3個(gè)面試必問核心點(diǎn)與代碼實(shí)戰(zhàn)
官方文檔堆砌著數(shù)百頁的API說明，翻得人頭大卻抓不住重點(diǎn)，這種痛苦每個(gè)搞技術(shù)的都懂。但當(dāng)你把視線從枯燥的文字移開，聚焦到“在行app”這個(gè)具體產(chǎn)品時(shí)，面試必問的那些高頻考點(diǎn)瞬間就活了。
別被名字誤導(dǎo)，“在行app”在這里并非指代某個(gè)特定的社交軟件，而是我們在面試突擊中構(gòu)建的一個(gè)典型高并發(fā)專家咨詢平臺模型。為什么選它？因?yàn)樗臉I(yè)務(wù)場景——用戶提問、專家接單、即時(shí)溝通、異步交付——完美覆蓋了后端開發(fā)中狀態(tài)機(jī)管理、分布式鎖、消息隊(duì)列削峰這三大面試必問的硬核考點(diǎn)。
今天這篇，不整虛的，直接對著這個(gè)模型拆解。我們將按照【對比式結(jié)構(gòu)】，把常見的錯(cuò)誤答法與標(biāo)準(zhǔn)答法做對比，用代碼把原理釘死，最后給你一套記憶口訣，讓你下次被問到類似問題時(shí)，能像老手一樣從容應(yīng)對。
考點(diǎn)梳理:為什么面試官愛問“在行”場景
很多候選人一聽到“設(shè)計(jì)一個(gè)咨詢系統(tǒng)”，腦子里全是CRUD，這是大忌。面試官問“在行app”這類場景，核心考點(diǎn)其實(shí)只有三個(gè)維度：訂單狀態(tài)的一致性：從“待接單”到“已交付”，中間涉及多角色操作，如何防止?fàn)顟B(tài)錯(cuò)亂？
高并發(fā)下的資源競爭：熱門專家同時(shí)被100人搶單，如何保證不超賣？
異步交互的可靠性：消息發(fā)送了但對方?jīng)]收到，或者專家回復(fù)了但用戶端沒刷新，怎么保證最終一致性？錯(cuò)誤認(rèn)知對比：初級答法：用數(shù)據(jù)庫事務(wù)包裹整個(gè)流程，加行鎖解決并發(fā)。后果：數(shù)據(jù)庫連接池瞬間打滿，系統(tǒng)直接崩盤，這在面試中屬于“一票否決”。高級答法：引入Redis做預(yù)扣減，MQ做異步解耦，數(shù)據(jù)庫只做最終落庫。后果：抗壓能力強(qiáng)，架構(gòu)清晰，這才是大廠想聽的。記住，面試官問的不是“怎么做”，而是“為什么這么做”以及“這么做的代價(jià)是什么”。
標(biāo)準(zhǔn)答法:構(gòu)建狀態(tài)機(jī)與并發(fā)控制模型
在“在行app”模型中，最核心的實(shí)體是ConsultOrder（咨詢訂單）。一個(gè)標(biāo)準(zhǔn)的訂單生命周期如下：
CREATED (已創(chuàng)建) - ACCEPTED (專家已接單) - IN_PROGRESS (咨詢中) - FINISHED (已完成) - EVALUATED (已評價(jià))
這里有兩個(gè)面試必問的深水區(qū)：
1. 狀態(tài)流轉(zhuǎn)的合法性校驗(yàn)
你不能直接從CREATED跳到FINISHED。面試中，要強(qiáng)調(diào)使用**狀態(tài)機(jī)模式（State Machine Pattern）**來管理。不要在業(yè)務(wù)代碼里寫滿if (status == 1) { ... }，那樣代碼維護(hù)起來是噩夢。
2. 搶單場景的分布式鎖
假設(shè)專家A有10個(gè)咨詢名額，瞬間來了100個(gè)請求。方案A：數(shù)據(jù)庫樂觀鎖。update orders set status=1 where status=0 and expert_id=1 limit 1。缺點(diǎn)：數(shù)據(jù)庫壓力大，且在高并發(fā)下性能瓶頸明顯。方案B：Redis分布式鎖 + Lua腳本。優(yōu)點(diǎn)：原子性強(qiáng)，性能高，是主流互聯(lián)網(wǎng)公司的標(biāo)準(zhǔn)答案。標(biāo)準(zhǔn)話術(shù)模板：
“在處理‘在行app’這類高并發(fā)咨詢平臺時(shí)，我會(huì)將訂單狀態(tài)管理與資源搶占分離。對于狀態(tài)流轉(zhuǎn)，采用狀態(tài)機(jī)模式確保邏輯嚴(yán)密；對于專家名額的搶占，采用Redis原子操作進(jìn)行預(yù)扣減，通過Lua腳本保證檢查與扣減的原子性，最后通過MQ異步通知數(shù)據(jù)庫持久化，以解決高并發(fā)下的性能與一致性問題?！?代碼實(shí)現(xiàn):Redis Lua腳本解決超賣問題
光說不練假把式。面試中如果允許白板編程或手撕代碼，這一段就是你的得分點(diǎn)。以下是基于Redis的Lua腳本，用于解決“專家咨詢名額”的超賣問題。
-- KEYS[1]: expert_quota_key (專家剩余名額Key, 例如: expert:quota:1001)
-- KEYS[2]: order_lock_key (訂單創(chuàng)建鎖Key, 防止同一用戶重復(fù)提交)
-- ARGV[1]: user_id (當(dāng)前請求的用戶ID)
-- ARGV[2]: expire_time (鎖的過期時(shí)間，秒)-- 1. 檢查用戶是否已經(jīng)持有鎖，防止重復(fù)提交
if redis.call(exists, KEYS[2] .. : .. ARGV[1]) == 1 thenreturn USER_LOCKED
end-- 2. 檢查專家剩余名額
local remaining = tonumber(redis.call(get, KEYS[1]))
if remaining == nil thenreturn KEY_NOT_FOUND
endif remaining = 0 thenreturn NO_QUOTA
end-- 3. 原子扣減名額
redis.call(decr, KEYS[1])-- 4. 設(shè)置用戶鎖，防止短時(shí)間內(nèi)的重復(fù)請求
-- 使用setex確保鎖的原子性設(shè)置
redis.call(setex, KEYS[2] .. : .. ARGV[1], ARGV[2], 1)return SUCCESS代碼逐行解析（面試加分項(xiàng)）：防重邏輯：KEYS[2] .. : .. ARGV[1] 構(gòu)造了以用戶ID為后綴的鎖Key。如果一個(gè)用戶手抖點(diǎn)了兩次“咨詢”，第二次請求進(jìn)來時(shí)，exists檢查會(huì)發(fā)現(xiàn)鎖已存在，直接返回USER_LOCKED。這比單純扣減名額更嚴(yán)謹(jǐn)，因?yàn)樗谌肟谔幘蛿r截了無效請求。
原子性保障：Lua腳本在Redis中是原子執(zhí)行的。從get到decr再到setex，中間不會(huì)插入其他客戶端的操作。這就避免了經(jīng)典的“檢查-執(zhí)行”競態(tài)條件（Race Condition）。
返回碼設(shè)計(jì)：返回字符串而非數(shù)字，便于Java/Go端直接映射為枚舉狀態(tài)，減少類型轉(zhuǎn)換開銷。Java端調(diào)用示例（偽代碼）：
public String tryAcquireQuota(String expertId, String userId) {String quotaKey = expert:quota: + expertId;String lockKey = order:lock: + expertId;// 定義Lua腳本String script = if redis.call('exists', KEYS[2] .. ':' .. ARGV[1]) == 1 then return 'USER_LOCKED' end +local remaining = tonumber(redis.call('get', KEYS[1])) +if remaining == nil then return 'KEY_NOT_FOUND' end +if remaining = 0 then return 'NO_QUOTA' end +redis.call('decr', KEYS[1]) +redis.call('setex', KEYS[2] .. ':' .. ARGV[1], ARGV[2], '1') +return 'SUCCESS';Object result = redisTemplate.execute(new DefaultRedisScript(script, String.class),Arrays.asList(quotaKey, lockKey),userId,30 // 鎖過期時(shí)間30秒);return (String) result;
}追問與延伸:當(dāng)Redis掛了怎么辦？
面試官聽到這里，通常會(huì)追問：“如果Redis節(jié)點(diǎn)宕機(jī)，或者網(wǎng)絡(luò)分區(qū)導(dǎo)致Lua腳本執(zhí)行了一半失敗，數(shù)據(jù)不一致怎么辦？”
這是區(qū)分中級和高級的關(guān)鍵點(diǎn)。你需要展示對最終一致性的理解。
標(biāo)準(zhǔn)應(yīng)對策略：Redis數(shù)據(jù)持久化：強(qiáng)調(diào)Redis開啟了AOF（Append Only File）持久化，且策略為everysec，最多丟失1秒數(shù)據(jù)。對于咨詢訂單這種非資金類場景，1秒的誤差是可接受的。
數(shù)據(jù)庫兜底校驗(yàn)：Redis只是“預(yù)扣減”。當(dāng)用戶真正下單時(shí)，Java服務(wù)會(huì)向MySQL發(fā)起請求。SQL語句中包含狀態(tài)檢查：
UPDATE consult_order
SET status = 'ACCEPTED', expert_id = #{expertId}
WHERE id = #{orderId} AND status = 'CREATED';如果影響行數(shù)為0，說明狀態(tài)已變或訂單不存在，此時(shí)需要觸發(fā)補(bǔ)償機(jī)制。
對賬任務(wù)：定時(shí)任務(wù)掃描Redis中的剩余名額與數(shù)據(jù)庫中的實(shí)際占用情況。如果Redis顯示有名額但數(shù)據(jù)庫里沒有對應(yīng)訂單，說明數(shù)據(jù)漂移，觸發(fā)告警并人工介入或自動(dòng)修正。延伸考點(diǎn)：消息隊(duì)列的作用
在Redis扣減成功后，不要直接同步寫數(shù)據(jù)庫。應(yīng)該發(fā)送一條OrderCreated消息到Kafka或RocketMQ。好處1：削峰填谷。數(shù)據(jù)庫壓力被平滑。
好處2：解耦。通知服務(wù)、短信服務(wù)、專家端App推送服務(wù)都監(jiān)聽這條消息，各自處理，互不阻塞。
好處3：事務(wù)消息。利用RocketMQ的事務(wù)消息機(jī)制，確?！癛edis扣減”與“MQ消息發(fā)送”的邏輯一致性。如果Redis扣減成功但MQ發(fā)送失敗，可以通過本地事務(wù)表或死信隊(duì)列進(jìn)行重試。記憶口訣:狀態(tài)鎖隊(duì)兜底
為了讓你在面試緊張時(shí)能瞬間回憶起這套組合拳，送你一個(gè)口訣：
“狀態(tài)機(jī)管流轉(zhuǎn)，Redis鎖防超賣，Lua原子扣名額，MQ異步解耦壓，數(shù)據(jù)庫兜底查，對賬任務(wù)保無差?！睜顟B(tài)機(jī)管流轉(zhuǎn)：別用if-else，用狀態(tài)機(jī)。
Redis鎖防超賣：高并發(fā)先想Redis。
Lua原子扣名額：檢查+扣減要原子。
MQ異步解耦壓：別同步寫庫，要發(fā)消息。
數(shù)據(jù)庫兜底查：SQL里加狀態(tài)條件，防并發(fā)錯(cuò)亂。
對賬任務(wù)保無差：最終一致性靠對賬。最后，關(guān)于“在行app”這個(gè)模型，還有一個(gè)容易被忽略的細(xì)節(jié)：超時(shí)取消機(jī)制。
如果專家接單后長時(shí)間不回復(fù)，或者用戶支付后專家未開始咨詢，訂單需要自動(dòng)回滾。這需要用到延遲隊(duì)列。在Redis中可以使用ZSET（有序集合）實(shí)現(xiàn)，Score為執(zhí)行時(shí)間戳，消費(fèi)者輪詢到期Key并執(zhí)行取消邏輯。或者直接使用RocketMQ的延遲消息功能，發(fā)送一條延遲15分鐘的OrderTimeout消息。
避坑指南：
千萬不要在代碼里用Thread.sleep或者Timer來實(shí)現(xiàn)延遲取消，這在分布式環(huán)境下是完全不可靠的。必須依賴中間件的消息調(diào)度能力。
實(shí)戰(zhàn)建議：
在準(zhǔn)備面試時(shí)，不要只背概念。建議你畫一張架構(gòu)圖，把“在行app”的請求鏈路畫出來：用戶端 - API網(wǎng)關(guān) - 訂單服務(wù)(Redis+Lua) - MQ - 數(shù)據(jù)庫/通知服務(wù)。對著圖講，邏輯最清晰。
你公司項(xiàng)目里是怎么處理高并發(fā)搶單或資源鎖定的？是用的Redis還是數(shù)據(jù)庫？歡迎評論分享你的實(shí)戰(zhàn)經(jīng)驗(yàn)，我們一起避坑。