1. 項(xiàng)目概述與整體設(shè)計(jì)思路1.1 這個(gè)模塊到底要解決什么問題蒼穹外賣的訂單模塊光是把“用戶下單→商家接單→配送完成”這條主鏈路跑通其實(shí)只是完成了最基本的功能。真正讓系統(tǒng)“好用”的反而是那些不起眼的旁路邏輯訂單超時(shí)了沒人處理怎么辦、用戶下單后商家沒聽見怎么辦、用戶等急了怎么催單。這三件事看起來簡(jiǎn)單但在真實(shí)業(yè)務(wù)里每一件都會(huì)直接影響用戶體驗(yàn)和商家口碑。我最初接手這個(gè)模塊時(shí)第一反應(yīng)是“這不就是三個(gè)定時(shí)任務(wù)加幾個(gè)接口嘛”。真做起來才發(fā)現(xiàn)訂單狀態(tài)定時(shí)處理、來單提醒、客戶催單這三塊每一塊背后都牽扯到狀態(tài)機(jī)設(shè)計(jì)、任務(wù)調(diào)度策略、實(shí)時(shí)推送通道、并發(fā)控制等等一系列問題。如果只盯著“把功能實(shí)現(xiàn)出來”那代碼可能很快就能跑通但一旦遇到高并發(fā)、服務(wù)器重啟、訂單狀態(tài)錯(cuò)亂這些場(chǎng)景就會(huì)連環(huán)踩坑。這個(gè)模塊適合誰(shuí)參考一種是正在做蒼穹外賣項(xiàng)目、想把訂單模塊做得更扎實(shí)的同學(xué)另一種是工作中要處理類似“超時(shí)關(guān)單實(shí)時(shí)提醒用戶主動(dòng)觸發(fā)”這類業(yè)務(wù)場(chǎng)景的開發(fā)者。我會(huì)把三塊功能拆開講每塊都會(huì)給出可落地的方案和我在實(shí)踐中踩過的坑。1.2 三塊功能的技術(shù)選型概覽在設(shè)計(jì)這個(gè)模塊時(shí)我首先梳理了三塊功能各自的本質(zhì)訂單狀態(tài)定時(shí)處理本質(zhì)是一個(gè)“到了某個(gè)時(shí)間點(diǎn)批量掃描并更新狀態(tài)”的定時(shí)任務(wù)。核心難點(diǎn)在于任務(wù)執(zhí)行時(shí)機(jī)、掃描效率、狀態(tài)流轉(zhuǎn)的冪等性。來單提醒本質(zhì)是一個(gè)“訂單創(chuàng)建后把消息實(shí)時(shí)推送給商家”的異步通知。核心難點(diǎn)在于推送通道的選擇、消息不丟失、商家在線/離線的差異化處理。客戶催單本質(zhì)是一個(gè)“用戶主動(dòng)觸發(fā)系統(tǒng)檢查訂單狀態(tài)并再次提醒商家”的交互接口。核心難點(diǎn)在于催單的頻率控制、狀態(tài)校驗(yàn)、與定時(shí)任務(wù)的配合。方案選型上我的思路是這樣的定時(shí)任務(wù)先用Spring自帶的Scheduled把功能跑通后續(xù)再考慮引入分布式任務(wù)調(diào)度平臺(tái)提醒推送優(yōu)先走WebSocket同時(shí)保留瀏覽器通知作為降級(jí)方案催單接口則基于訂單狀態(tài)機(jī)做嚴(yán)格校驗(yàn)避免用戶亂催、重復(fù)催。下面逐個(gè)展開。2. 來單提醒的推送鏈路與信息觸達(dá)設(shè)計(jì)2.1 為什么來單提醒要“先抄后推”來單提醒看起來就是“商家端收到一個(gè)新訂單”但如果直接在前端輪詢訂單列表又費(fèi)流量又不實(shí)時(shí)。輪詢間隔短了數(shù)據(jù)庫(kù)壓力大間隔長(zhǎng)了用戶下單后商家要等好幾秒才知道體驗(yàn)很差。更好的做法是“先抄后推”訂單創(chuàng)建成功后先把數(shù)據(jù)落庫(kù)確保訂單一定不會(huì)丟然后再通過WebSocket把“有新訂單”這個(gè)事件推給商家端。也就是訂單主流程不依賴推送結(jié)果推送成功與否都不影響訂單正常生成。我剛開始做的時(shí)候差點(diǎn)把推送寫成同步調(diào)用后來想明白一個(gè)道理如果推送服務(wù)掛了難道用戶連單都下不了嗎肯定不行。這種設(shè)計(jì)的好處有三個(gè)第一訂單主鏈路簡(jiǎn)單可靠第二推送是異步的不拖慢下單響應(yīng)時(shí)間第三即使推送失敗商家端仍然可以通過訂單列表主動(dòng)刷新看到新訂單只是“提醒”這個(gè)增強(qiáng)體驗(yàn)丟了而已。所以我把推送邏輯放在訂單創(chuàng)建成功之后的事件發(fā)布環(huán)節(jié)通過Spring的ApplicationEventPublisher發(fā)一個(gè)事件再由監(jiān)聽器異步處理推送實(shí)現(xiàn)了主鏈路和解耦。2.2 多端觸達(dá)瀏覽器通知、WebSocket、短信的取舍來單提醒不能只依賴一條通道因?yàn)樯碳叶丝赡芴幱诓煌臓顟B(tài)網(wǎng)頁(yè)開著但不一定盯著看、瀏覽器標(biāo)簽頁(yè)被切走了、甚至商家根本不在電腦前。我在實(shí)際開發(fā)中把觸達(dá)渠道按優(yōu)先級(jí)分成了三層WebSocket實(shí)時(shí)推送商家端在線時(shí)最優(yōu)先使用。連接建立后服務(wù)端一旦檢測(cè)到新訂單立即推送“來單提醒”消息商家端彈窗提示音。這是整個(gè)提醒功能的主力通道。瀏覽器通知Notification API當(dāng)商家端的WebSocket連接存在但頁(yè)面處于后臺(tái)標(biāo)簽頁(yè)時(shí)單純靠頁(yè)面內(nèi)彈窗是看不見的。這時(shí)用瀏覽器原生通知即使不在當(dāng)前標(biāo)簽頁(yè)也能看到系統(tǒng)級(jí)彈窗。短信/電話提醒這屬于重型觸達(dá)一般只在商家長(zhǎng)時(shí)間不接單、訂單即將超時(shí)或被客戶催單時(shí)才會(huì)觸發(fā)。因?yàn)槎绦庞谐杀径胰菀自斐沈}擾所以不能當(dāng)作默認(rèn)通道。我的建議是先把WebSocket和瀏覽器通知做好短信通道做成一個(gè)可擴(kuò)展的接口后續(xù)接第三方短信平臺(tái)時(shí)只需要實(shí)現(xiàn)同一個(gè)接口即可。這樣既不會(huì)在初期被短信成本拖累又保留了后續(xù)迭代的空間。2.3 提醒內(nèi)容模板與防騷擾策略來單提醒的內(nèi)容設(shè)計(jì)也有講究。最初我只推了一個(gè)“您有新的訂單”商家點(diǎn)進(jìn)去還要再查一遍訂單詳情多了一步操作。后來我把推送內(nèi)容直接拼裝成包含關(guān)鍵信息的模板商家在彈窗里就能看到主要內(nèi)容例如訂單號(hào)、用戶手機(jī)號(hào)后四位、訂單金額、預(yù)計(jì)送達(dá)時(shí)間、備注信息等。{ type: NEW_ORDER, data: { orderId: 1024, orderNumber: 2025011512345678, amount: 68.5, expectDeliveryTime: 2025-01-15 12:30, remark: 不要辣多放蔥, timestamp: 1736901234000 } }防騷擾策略這塊很多人會(huì)忽略。我遇到過一個(gè)問題商家端WebSocket重連時(shí)服務(wù)端會(huì)把連接期間積累的訂單全部補(bǔ)推一遍結(jié)果商家收到十幾個(gè)提醒彈窗體驗(yàn)極差。后來我加了一個(gè)規(guī)則同一個(gè)商家端連接收到重復(fù)推送時(shí)前端做去重服務(wù)端則只推送“當(dāng)前時(shí)間點(diǎn)之后的新訂單”歷史訂單通過列表接口加載不通過推送補(bǔ)發(fā)。另外為了避免同一訂單被反復(fù)提醒我在訂單表里加了remind_status字段標(biāo)記該訂單是否已經(jīng)推送過推送成功則置為已推送防止重復(fù)提醒。3. 客戶催單的實(shí)現(xiàn)與超時(shí)訂單的自動(dòng)化閉環(huán)3.1 催單按鈕的前后端聯(lián)動(dòng)客戶催單的業(yè)務(wù)背景很好理解用戶下單后如果商家遲遲不接單用戶等得著急于是發(fā)起催單系統(tǒng)需要把這個(gè)訴求轉(zhuǎn)達(dá)給商家并且要給出反饋。用戶在C端“催單”按鈕點(diǎn)擊后前端調(diào)用后端接口后端需要做三件事校驗(yàn)訂單是否可以催單、記錄催單事件、觸發(fā)對(duì)商家的再次提醒。后端接口的核心邏輯我設(shè)計(jì)成下面這樣PostMapping(/remind/{orderId}) ApiOperation(客戶催單) public ResultString remind(PathVariable Long orderId) { // 1. 查詢訂單 Order order orderMapper.getById(orderId); if (order null) { throw new OrderBusinessException(MessageConstant.ORDER_NOT_FOUND); } // 2. 校驗(yàn)訂單狀態(tài)只有待接單狀態(tài)才允許催單 if (!OrderStatus.PENDING_PAYMENT.equals(order.getStatus())) { throw new OrderBusinessException(MessageConstant.ORDER_STATUS_ERROR); } // 3. 記錄催單事件同一訂單短時(shí)間內(nèi)不能重復(fù)催 if (remindService.isFrequent(orderId, LocalDateTime.now())) { throw new OrderBusinessException(MessageConstant.REMIND_TOO_FREQUENT); } remindService.save(orderId, userId, LocalDateTime.now()); // 4. 觸發(fā)商家提醒 orderRemindService.sendRemindAgain(order); return Result.success(); }前端收到成功響應(yīng)后會(huì)彈一個(gè)“已提醒商家盡快接單”的提示同時(shí)按鈕進(jìn)入冷卻狀態(tài)比如3分鐘內(nèi)不可再次點(diǎn)擊。這個(gè)冷卻時(shí)間其實(shí)是我在實(shí)操中根據(jù)用戶反饋調(diào)整的最開始設(shè)的1分鐘結(jié)果有用戶連續(xù)點(diǎn)了好幾次商家端被反復(fù)打擾后來統(tǒng)一調(diào)整為3分鐘體驗(yàn)才正常。3.2 狀態(tài)機(jī)校驗(yàn)催單不是“想催就能催”催單接口最容易漏掉的一點(diǎn)是狀態(tài)校驗(yàn)。如果不加狀態(tài)判斷用戶對(duì)已完成的訂單也能發(fā)起催單這顯然不合理。我維護(hù)了一套訂單狀態(tài)機(jī)定義了訂單從“待支付→待接單→已接單→派送中→已完成→已取消”的流轉(zhuǎn)規(guī)則然后把催單接口死死地限制在“待接單”和“派送中”兩個(gè)狀態(tài)。為什么不給“待支付”狀態(tài)開放催單因?yàn)橛脩暨€沒付錢壓根不存在“商家不處理”的問題。為什么不給“已接單”開放催單商家已經(jīng)在做了再催就是打擾干活。真正需要催的是商家遲遲不接單待接單或配送太久派送中這兩種場(chǎng)景。狀態(tài)機(jī)的價(jià)值就在這里它不是限制功能而是讓功能出現(xiàn)在真正需要它的場(chǎng)景里。3.3 超時(shí)未處理的自動(dòng)提醒鏈路只靠用戶手動(dòng)催單是不夠的很多用戶不會(huì)主動(dòng)點(diǎn)催單或者壓根沒注意到訂單卡住了。所以系統(tǒng)還需要一條“自動(dòng)催”的鏈路訂單進(jìn)入待接單狀態(tài)后超過一定時(shí)間商家仍未接單系統(tǒng)就自動(dòng)執(zhí)行一次提醒甚至同步觸發(fā)短信通知商家。這條鏈路本質(zhì)上依賴定時(shí)任務(wù)。我在蒼穹外賣里做的是每分鐘掃描一次訂單表篩選出“狀態(tài)為待接單、且下單時(shí)間超過5分鐘”的訂單對(duì)這些訂單發(fā)起一次催單提醒。同時(shí)為了不讓商家被無限騷擾同一訂單的自動(dòng)提醒最多觸發(fā)3次超過次數(shù)后會(huì)轉(zhuǎn)入異常訂單列表后續(xù)由人工介入處理。這種設(shè)計(jì)把“用戶主動(dòng)催”和“系統(tǒng)自動(dòng)催”結(jié)合了起來覆蓋了大多數(shù)超時(shí)場(chǎng)景。做的時(shí)候我特意留意了掃描SQL的寫法一定要在status和create_time上建聯(lián)合索引否則訂單量一旦上來每分鐘一次的全表掃描會(huì)把數(shù)據(jù)庫(kù)拖垮。4. 定時(shí)任務(wù)框架選型從Spring Schedule到分布式方案4.1 Spring Schedule的適用邊界蒼穹外賣項(xiàng)目里定時(shí)任務(wù)我用的Spring自帶的Scheduled原因很直接項(xiàng)目規(guī)模可控、不需要復(fù)雜的任務(wù)編排、部署方式還是單機(jī)部署殺雞不用牛刀。Spring Schedule用起來也確實(shí)方便一個(gè)注解加一個(gè)方法就能搞定。Component Slf4j public class OrderTask { Scheduled(cron 0 * * * * ?) // 每分鐘執(zhí)行一次 public void processTimeoutOrder() { log.info(定時(shí)處理超時(shí)訂單開始); // 處理待支付超時(shí)訂單、待接單超時(shí)訂單等 orderService.processTimeoutOrder(); log.info(定時(shí)處理超時(shí)訂單結(jié)束); } }但Spring Schedule的短板也很明確單機(jī)執(zhí)行沒有任務(wù)分片能力沒有失敗重試機(jī)制沒有任務(wù)執(zhí)行記錄的可視化界面。一旦服務(wù)部署多個(gè)實(shí)例同一個(gè)任務(wù)會(huì)在每個(gè)實(shí)例上都執(zhí)行一遍如果沒有做好冪等控制就可能出現(xiàn)重復(fù)處理。所以我對(duì)Spring Schedule的定位是“單機(jī)場(chǎng)景夠用分布場(chǎng)景慎用”。4.2 分布式定時(shí)任務(wù)的演進(jìn)路線如果蒼穹外賣后續(xù)要做成微服務(wù)架構(gòu)、多實(shí)例部署那定時(shí)任務(wù)必須遷移到分布式方案。目前主流的思路有兩條引入XXL-JOB一個(gè)輕量級(jí)的分布式任務(wù)調(diào)度平臺(tái)支持任務(wù)分片廣播、失敗重試、動(dòng)態(tài)調(diào)整cron表達(dá)式、執(zhí)行日志可視化。部署時(shí)通過調(diào)度中心統(tǒng)一觸發(fā)任務(wù)執(zhí)行器節(jié)點(diǎn)只負(fù)責(zé)干活天然解決了多實(shí)例重復(fù)執(zhí)行的問題。基于Spring Cloud Redis分布式鎖不引入額外中間件通過Redis的SETNX實(shí)現(xiàn)一個(gè)分布式鎖多實(shí)例搶到鎖的節(jié)點(diǎn)才執(zhí)行定時(shí)任務(wù)。優(yōu)點(diǎn)是輕量缺點(diǎn)是任務(wù)沒有分片能力同一時(shí)刻只有一個(gè)節(jié)點(diǎn)在跑并發(fā)吞吐受限。這兩條路我都實(shí)地調(diào)研過。對(duì)于蒼穹外賣這種體量的項(xiàng)目我傾向于先上Redis分布式鎖因?yàn)槌杀镜汀⒏脑炜熳阋灾稳粘Ａ髁康葮I(yè)務(wù)量明顯增長(zhǎng)、需要任務(wù)拆分并行執(zhí)行時(shí)再平滑遷移到XXL-JOB。定時(shí)任務(wù)這件事最忌諱一上來就上重武器先把簡(jiǎn)單的方案用好比盲目堆架構(gòu)更實(shí)在。4.3 蒼穹外賣采用的方案與取舍回到蒼穹外賣這個(gè)具體項(xiàng)目。我的最終落地組合是Spring Schedule做基礎(chǔ)定時(shí)調(diào)度 Redis分布式鎖做多實(shí)例互斥 狀態(tài)字段做業(yè)務(wù)冪等。也就是說即使以后部署了多個(gè)實(shí)例同一個(gè)任務(wù)同一時(shí)刻只有一個(gè)實(shí)例在跑即使任務(wù)執(zhí)行過程中出現(xiàn)異常中斷重跑時(shí)也不會(huì)把已處理過的訂單再處理一遍。這里有個(gè)細(xì)節(jié)值得多說一句冪等控制不能只靠分布式鎖因?yàn)殒i只能管住“同一時(shí)刻”管不住“下次執(zhí)行”。如果處理邏輯本身就存在臟數(shù)據(jù)問題即使鎖完全沒問題也可能重復(fù)更新狀態(tài)。所以我在更新訂單狀態(tài)的SQL里永遠(yuǎn)帶上狀態(tài)條件例如只有當(dāng)前狀態(tài)是“待接單”才能更新為“已接單”這樣即使任務(wù)重跑也不會(huì)影響已經(jīng)流轉(zhuǎn)到下一狀態(tài)的訂單。5. 實(shí)操中的坑與排查實(shí)錄5.1 定時(shí)任務(wù)“丟跑”與重復(fù)執(zhí)行的根因定時(shí)任務(wù)最常見的問題就是“丟了”或者“重復(fù)跑”。我在測(cè)試階段遇到過這么一件事定時(shí)任務(wù)設(shè)置為每分鐘執(zhí)行一次某次手動(dòng)觸發(fā)后日志里出現(xiàn)了兩條“開始處理”記錄。排查后發(fā)現(xiàn)是因?yàn)闇y(cè)試環(huán)境的訂單服務(wù)部署了兩個(gè)實(shí)例兩個(gè)實(shí)例的Scheduled同時(shí)觸發(fā)導(dǎo)致同一批訂單被掃描了兩次。雖然在SQL層面做了狀態(tài)條件拼接數(shù)據(jù)沒出大問題但日志里看起來非常瘆人。解決辦法就是我前面提到的Redis分布式鎖。我在任務(wù)入口處加了一個(gè)SETNX鎖鎖的key用任務(wù)名稱過期時(shí)間設(shè)為55秒這樣即使兩個(gè)實(shí)例同時(shí)觸發(fā)也只有搶到鎖的那個(gè)實(shí)例能繼續(xù)執(zhí)行另一個(gè)直接返回。這里還有一個(gè)小坑鎖的過期時(shí)間如果小于任務(wù)實(shí)際執(zhí)行時(shí)間任務(wù)還沒跑完鎖就自動(dòng)釋放了另一個(gè)實(shí)例會(huì)再次搶到鎖導(dǎo)致重復(fù)執(zhí)行。所以過期時(shí)間一定要大于任務(wù)的最大執(zhí)行時(shí)長(zhǎng)最好留出余量并在任務(wù)結(jié)束后主動(dòng)釋放鎖。5.2 數(shù)據(jù)庫(kù)時(shí)間與服務(wù)器時(shí)區(qū)不一致這個(gè)坑非常隱蔽也很致命。某個(gè)訂單的超時(shí)時(shí)間明明設(shè)置的是12:00但定時(shí)任務(wù)執(zhí)行后發(fā)現(xiàn)訂單在13:00才被處理。排查了半天最終發(fā)現(xiàn)是服務(wù)器時(shí)區(qū)和數(shù)據(jù)庫(kù)時(shí)區(qū)不一致數(shù)據(jù)庫(kù)連接串里設(shè)置的serverTimezoneAsia/Shanghai但服務(wù)器系統(tǒng)時(shí)區(qū)是UTC導(dǎo)致NOW()函數(shù)取到的時(shí)間和Java本地時(shí)間差了8個(gè)小時(shí)。從那以后我定了個(gè)規(guī)矩所有時(shí)間字段一律以數(shù)據(jù)庫(kù)時(shí)間為準(zhǔn)Java側(cè)不依賴系統(tǒng)默認(rèn)時(shí)區(qū)連接串顯式指定serverTimezOne并且在項(xiàng)目啟動(dòng)時(shí)統(tǒng)一設(shè)置TimeZone.setDefault(TimeZone.getTimeZone(Asia/Shanghai))。定時(shí)任務(wù)涉及時(shí)間判斷的SQL能不用應(yīng)用層時(shí)間就不用直接寫數(shù)據(jù)庫(kù)函數(shù)從根源上避免時(shí)區(qū)偏差。5.3 WebSocket連接斷開與重連來單提醒的WebSocket連接在實(shí)際運(yùn)營(yíng)中經(jīng)常會(huì)出現(xiàn)“悄悄斷開”的情況。服務(wù)端推送時(shí)報(bào)錯(cuò)才發(fā)現(xiàn)商家端連接早就斷了但前端還不知道。我做了一個(gè)簡(jiǎn)單的保活機(jī)制前端每30秒發(fā)送一個(gè)心跳ping服務(wù)端收到后回一個(gè)pong如果連續(xù)三次心跳都沒收到服務(wù)端回復(fù)前端就主動(dòng)斷開并重新建立連接服務(wù)端也在注冊(cè)一個(gè)空閑檢測(cè)超過一定時(shí)間沒收到心跳就主動(dòng)關(guān)閉連接。另外服務(wù)端推送消息時(shí)需要捕獲連接斷開異常不能因?yàn)槟硞€(gè)商家端連接異常就把整個(gè)推送線程搞崩。我封裝了一個(gè)sendToUser方法推送時(shí)先檢查session.isOpen()再發(fā)送發(fā)送失敗就記錄日志并移除這個(gè)連接。不要小看這個(gè)細(xì)節(jié)在真實(shí)環(huán)境中商家的電腦可能隨時(shí)休眠、網(wǎng)絡(luò)可能隨時(shí)切換WebSocket連接穩(wěn)定性是來單提醒功能能否真正落地的關(guān)鍵。6. 幾點(diǎn)經(jīng)驗(yàn)總結(jié)6.1 狀態(tài)機(jī)是訂單系統(tǒng)的靈魂做了這個(gè)模塊之后我最大的一個(gè)體會(huì)是訂單系統(tǒng)的核心不是接口寫得多花哨而是狀態(tài)機(jī)設(shè)計(jì)得夠不夠嚴(yán)謹(jǐn)。定時(shí)處理、來單提醒、客戶催單這三塊功能最終都是在跟訂單狀態(tài)打交道。狀態(tài)流轉(zhuǎn)定義清楚了代碼自然好寫狀態(tài)流轉(zhuǎn)模糊再簡(jiǎn)單的功能也會(huì)改出各種Bug。我建議大家在動(dòng)手寫代碼之前先花半小時(shí)把訂單的完整狀態(tài)圖畫出來把“誰(shuí)觸發(fā)了流轉(zhuǎn)”“流轉(zhuǎn)前需要滿足什么條件”“流轉(zhuǎn)后要做哪些后續(xù)動(dòng)作”都列出來。這張圖就是整個(gè)訂單模塊的設(shè)計(jì)藍(lán)圖后面所有功能的開發(fā)都圍繞它展開能省下很多返工時(shí)間。6.2 定時(shí)任務(wù)的監(jiān)控與告警定時(shí)任務(wù)跑得久了最容易出現(xiàn)的問題就是“靜默失敗”任務(wù)啟動(dòng)時(shí)報(bào)了個(gè)異常日志被打到某個(gè)不起眼的文件里然后整個(gè)訂單模塊的超時(shí)處理就癱瘓了而沒有任何人發(fā)現(xiàn)。所以我給大家一個(gè)很實(shí)用的建議定時(shí)任務(wù)必須有監(jiān)控。最簡(jiǎn)單的方式是在任務(wù)開始和結(jié)束時(shí)各打一條日志關(guān)鍵任務(wù)還要往數(shù)據(jù)庫(kù)寫一張task_execution_log表記錄每次執(zhí)行的起始時(shí)間、結(jié)束時(shí)間、處理數(shù)量、執(zhí)行結(jié)果。日常巡檢只看這張表就能知道任務(wù)有沒有準(zhǔn)時(shí)跑、跑了多少單、有沒有報(bào)錯(cuò)。更進(jìn)一步可以接一下企業(yè)微信/釘釘/飛書的webhook任務(wù)執(zhí)行異常時(shí)自動(dòng)發(fā)消息到工作群這樣不用人工盯日志就能第一時(shí)間發(fā)現(xiàn)問題。6.3 后續(xù)擴(kuò)展方向如果這個(gè)項(xiàng)目要繼續(xù)往下做我覺得有幾個(gè)方向可以延伸一是引入消息隊(duì)列如RocketMQ替代WebSocket直推讓推送能力與業(yè)務(wù)服務(wù)徹底解耦推送失敗時(shí)還能靠消息重試兜底二是把催單記錄沉淀成數(shù)據(jù)報(bào)表分析哪些時(shí)段商家接單最慢、哪些區(qū)域催單率最高反向指導(dǎo)商家改善出餐流程三是把訂單超時(shí)處理從“定時(shí)掃描”升級(jí)為“延遲消息”利用消息隊(duì)列的延遲隊(duì)列實(shí)現(xiàn)更精準(zhǔn)、更及時(shí)的超時(shí)觸發(fā)減少掃描帶來的無效計(jì)算。這些擴(kuò)展不一定要馬上做但心里得有這個(gè)圖譜等業(yè)務(wù)量上來的時(shí)候才知道該往哪個(gè)方向走。我到現(xiàn)在還記得第一次把這三塊功能完整跑通、商家在客戶端收到來單彈窗的時(shí)刻那種“系統(tǒng)真的活起來了”的感受是做技術(shù)的人最享受的瞬間。