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