簡介面向C#初學(xué)者和排隊(duì)機(jī)系統(tǒng)設(shè)計(jì)者這份源代碼完整呈現(xiàn)了一套可實(shí)際投產(chǎn)的排隊(duì)叫號系統(tǒng)。系統(tǒng)覆蓋取號、呼叫、窗口分配、候診屏同步顯示等核心業(yè)務(wù)流程并封裝了數(shù)據(jù)庫操作輔助類與常見硬件設(shè)備對接邏輯可幫助讀者理解工業(yè)級叫號項(xiàng)目的整體架構(gòu)與實(shí)現(xiàn)思路。項(xiàng)目已在真實(shí)客戶現(xiàn)場穩(wěn)定運(yùn)行多年整體代碼幾乎無保留界面與業(yè)務(wù)規(guī)則均可自行修改擴(kuò)展尤其適合正在為排隊(duì)機(jī)方案發(fā)愁的開發(fā)者做參考。壓縮包為rar格式共249個(gè)文件大小僅1.29MB其中以172個(gè)C#源碼文件為主另有44個(gè)resx資源文件、9個(gè)項(xiàng)目工程文件、2個(gè)rdlc報(bào)表文件以及設(shè)置、圖標(biāo)、用戶控件等輔助文件模塊劃分清晰便于按功能分段研讀與二次開發(fā)。目前已有1617人學(xué)習(xí)下載對希望快速上手WinForm數(shù)據(jù)庫開發(fā)、或需要完整叫號系統(tǒng)設(shè)計(jì)樣例的讀者而言這份穩(wěn)定可靠的實(shí)戰(zhàn)代碼能節(jié)省大量從零搭建的時(shí)間。1. 排隊(duì)機(jī)叫號一個(gè)把大廳廣播、小票打印和數(shù)據(jù)庫串起來的實(shí)時(shí)隊(duì)列系統(tǒng)在醫(yī)院分診臺取號小票打出來消化內(nèi)科 A012 前面還有 5 人到銀行網(wǎng)點(diǎn)拿身份證一刷柜臺呼叫下一位大屏同步閃出號碼和窗口號。這套熟悉得不能再熟悉的流程背后就是一個(gè)獨(dú)立的排隊(duì)機(jī)叫號系統(tǒng)。這份源碼不是某個(gè)大廠中間件而是一套完整的 C/S 架構(gòu)工程覆蓋了取號、叫號、過號、重呼、窗口分配、大屏展示、語音播報(bào)、業(yè)務(wù)量統(tǒng)計(jì)這些叫號系統(tǒng)該有的全部環(huán)節(jié)。適合三類人接政企外包需要做叫號交付的開發(fā)者、想在自己的業(yè)務(wù)系統(tǒng)里集成排隊(duì)模塊的技術(shù)負(fù)責(zé)人、以及正在學(xué) Socket 通信和 SQL Server 事務(wù)開發(fā)的初學(xué)者。技術(shù)選型偏傳統(tǒng)但架構(gòu)干凈核心就一條 TCP 消息鏈路加一張不斷變狀態(tài)的排隊(duì)表值得拆開看一遍。2. 系統(tǒng)拆解四端一中心一個(gè) TCP 消息把大廳串起來2.1 整體架構(gòu)排隊(duì)叫號本質(zhì)上是一個(gè)狀態(tài)機(jī)被消息推著走很多人第一次接觸叫號系統(tǒng)會以為難點(diǎn)在大屏 UI 或者語音播報(bào)其實(shí)拆開源碼看核心就是三個(gè)角色之間的消息流轉(zhuǎn)取號端負(fù)責(zé)發(fā)號窗口端負(fù)責(zé)叫號大屏端負(fù)責(zé)展示和播報(bào)而服務(wù)端是唯一能碰數(shù)據(jù)庫的角色。整個(gè)系統(tǒng)采用 Socket 長連接組網(wǎng)服務(wù)端作為消息中心四個(gè)程序通過網(wǎng)絡(luò)連接在一起。顧客在取號機(jī)上按下個(gè)人業(yè)務(wù)取號端把請求發(fā)給服務(wù)端服務(wù)端寫庫生成號碼再返回給取號端打印小票柜員在窗口端點(diǎn)呼叫下一個(gè)窗口端把指令發(fā)給服務(wù)端服務(wù)端更新數(shù)據(jù)庫里的排隊(duì)狀態(tài)然后主動(dòng)把叫號通知推給大屏端和語音端。數(shù)據(jù)庫在這一整套流程里只跟服務(wù)端打交道其他三個(gè)端都不直接讀寫數(shù)據(jù)庫。這種服務(wù)端收口數(shù)據(jù)庫的設(shè)計(jì)好處很明顯排隊(duì)狀態(tài)的任何變化都有唯一的數(shù)據(jù)入口不會出現(xiàn)窗口端和大屏端各改各的導(dǎo)致數(shù)據(jù)不一致。缺點(diǎn)是服務(wù)端一旦掛了整個(gè)大廳叫號就癱掉所以源碼里服務(wù)端也做了一些斷線重連和恢復(fù)處理后面的避坑章節(jié)會細(xì)說。2.2 工程目錄一次下載下來你會看到的項(xiàng)目結(jié)構(gòu)源碼解決方案是標(biāo)準(zhǔn)的 Visual Studio 結(jié)構(gòu)五個(gè)工程按職責(zé)切分得比較清楚QueueSystem/ ├── QueueServer.Svc/ 服務(wù)端程序含狀態(tài)機(jī)核心邏輯 │ ├── Core/ 隊(duì)列調(diào)度、過號掃描、恢復(fù)邏輯 │ ├── DB/ SQL Server 數(shù)據(jù)訪問層 │ └── SocketService/ TCP 監(jiān)聽、消息解析、客戶端會話管理 ├── QueueClient.Terminal/ 取號端程序觸摸屏取號機(jī)界面 ├── QueueClient.Window/ 窗口端程序柜員叫號操作界面 ├── QueueClient.Screen/ 大屏端程序LCD/LED 展示與語音播報(bào) ├── Queue.Common/ 公共類庫消息協(xié)議封裝、實(shí)體模型、日志組件 ├── DbScript/ │ └── QueueDB.sql 數(shù)據(jù)庫初始化腳本建庫建表基礎(chǔ)數(shù)據(jù) └── QueueSystem.sln服務(wù)端工程里最重要的目錄是Core和SocketService一個(gè)管隊(duì)列怎么排隊(duì)一個(gè)管消息怎么收發(fā)。Queue.Common是所有工程都引用的公共類庫消息幀的封包拆包、實(shí)體對象的序列化都在這。四個(gè)端共享同一套協(xié)議類這是通信不跑偏的基礎(chǔ)。每個(gè)客戶端工程里都有對應(yīng)的app.config或ApplicationConfig.config大屏端和窗口端配置服務(wù)端 IP 和端口取號端還可以額外配置小票打印機(jī)串口號。這套命名和結(jié)構(gòu)對做過 C/S 項(xiàng)目的人來說基本零門檻按圖索驥能找到所有入口。2.3 消息協(xié)議設(shè)計(jì)一條命令字 長度 JSON的幀協(xié)議四端之間傳的不是 XML 也不是對象流而是一種非常樸素的自定義文本協(xié)議消息幀格式是命令字|消息體長度|消息體消息體是一段 JSON 字符串。比如服務(wù)端向大屏推一條叫號通知實(shí)際在網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容是這樣SVR_CALL_NOTIFY|112|{QueueNO:A012,WindowNO:03,CallTime:2024-06-25 09:30:12}幀里的三個(gè)字段用豎線分割命令字標(biāo)識消息類型長度告訴接收方要讀滿多少字節(jié)才算一條完整消息JSON 承載具體業(yè)務(wù)數(shù)據(jù)。長度字段很關(guān)鍵因?yàn)?TCP 是流式傳輸接收方如果不按長度去湊夠一條消息就會出現(xiàn)一次 Read 拿到半條消息或者兩條消息粘在一起的情況。Queue.Common里對應(yīng)的封包拆包邏輯是這個(gè)樣子/// summary把一個(gè)命令字和消息體打包成一幀網(wǎng)絡(luò)消息/summary public static byte[] Pack(string cmd, object body) { // 把消息體序列化為 JSON 字符串 string json JsonConvert.SerializeObject(body); // 拼接成 命令字|長度|消息體 的幀格式 string frame ${cmd}|{json.Length}|{json}; // 轉(zhuǎn)成 UTF-8 字節(jié)返回給 Socket 發(fā)送 return Encoding.UTF8.GetBytes(frame); } /// summary從接收緩沖區(qū)里拆出一條完整的消息返回命令字和反序列化后的原始 JSON/summary public static bool TryParse(byte[] buffer, ref int offset, out string cmd, out string json) { cmd null; json null; // 先把緩沖區(qū)轉(zhuǎn)成字符串找第一個(gè)豎線分隔符截出命令字 string text Encoding.UTF8.GetString(buffer, offset, buffer.Length - offset); int firstSep text.IndexOf(|); if (firstSep 0) return false; cmd text.Substring(0, firstSep); // 再截出長度字段用 int.TryParse 解析出消息體應(yīng)該有多少個(gè)字符 int secondSep text.IndexOf(|, firstSep 1); int length int.Parse(text.Substring(firstSep 1, secondSep - firstSep - 1)); // 如果緩沖區(qū)里剩余字節(jié)數(shù)比消息體長度還少說明消息還沒收全返回 false if (text.Length - secondSep - 1 length) return false; // 按長度字段截出完整 JSON 消息體并更新偏移量 json text.Substring(secondSep 1, length); offset secondSep 1 length; return true; }這里的邏輯說明要展開兩點(diǎn)第一Pack里把 JSON 序列化和幀拼接做了合并調(diào)用方只傳命令字和業(yè)務(wù)對象不用關(guān)心轉(zhuǎn)義問題第二TryParse是增量解析服務(wù)端每個(gè) Socket 會話都持有一個(gè)緩沖區(qū)收到新數(shù)據(jù)就丟進(jìn)這個(gè)解析器能拆出完整消息才進(jìn)入業(yè)務(wù)分發(fā)。判斷消息沒收全的那個(gè)分支最容易寫錯(cuò)長度字段必須按 JSON 字符串的字符數(shù)計(jì)算如果按Encoding.UTF8.GetBytes(json).Length算字節(jié)數(shù)遇到中文就全亂套了這也是這份源碼里一個(gè)隱藏的易錯(cuò)點(diǎn)。命令字在Queue.Common里定義成了常量類稍大一點(diǎn)的系統(tǒng)建議改成枚舉但源碼用字符串常量也沒問題。常用的命令字有TERM_TAKE_NUMBER取號、WIN_CALL_NEXT叫下一位、WIN_FINISH辦結(jié)、SVR_CALL_NOTIFY叫號廣播、SVR_SCREEN_SNAP大屏隊(duì)列快照和HBT_HEARTBEAT心跳。3. 數(shù)據(jù)庫設(shè)計(jì)排隊(duì)表里的每一條記錄都在等狀態(tài)變化3.1 四張核心表隊(duì)列、窗口、業(yè)務(wù)類型和操作日志打開DbScript/QueueDB.sql往后面翻會發(fā)現(xiàn)整個(gè)排隊(duì)的業(yè)務(wù)數(shù)據(jù)落在四張表上T_BusinessType存業(yè)務(wù)類型個(gè)人業(yè)務(wù)、對公業(yè)務(wù)、掛失銷戶T_WindowInfo存窗口基礎(chǔ)信息T_QueueInfo是排隊(duì)明細(xì)主表T_QueueLog記錄每一次操作軌跡。其中T_QueueInfo.Status字段是整個(gè)系統(tǒng)的靈魂它用四個(gè)數(shù)字表示一條排隊(duì)記錄的完整生命周期-- 排隊(duì)明細(xì)主表一條記錄代表一張排隊(duì)小票 CREATE TABLE T_QueueInfo ( Id INT IDENTITY(1,1) PRIMARY KEY, -- 自增主鍵 QueueNO VARCHAR(10) NOT NULL, -- 叫號號碼例如 A012 TokenNO VARCHAR(20) NOT NULL, -- 小票流水號用于取票憑證和追溯 BusinessTypeId INT NOT NULL, -- 關(guān)聯(lián)業(yè)務(wù)類型表 WindowId INT NULL, -- 當(dāng)前服務(wù)的窗口ID未叫號時(shí)為NULL Status TINYINT NOT NULL DEFAULT 0, -- 0等待中 1已叫號 2已過號 3已完成 4已取消 CreateTime DATETIME NOT NULL DEFAULT GETDATE(), -- 取號時(shí)間 CallTime DATETIME NULL, -- 首次叫號時(shí)間過號判斷依賴這個(gè)字段 FinishTime DATETIME NULL, -- 辦結(jié)或取消時(shí)間 SourceType TINYINT NOT NULL DEFAULT 0 -- 0現(xiàn)場取號 1預(yù)約簽到擴(kuò)展用 );這張表的狀態(tài)流轉(zhuǎn)可以直觀理解為取號插入一條Status0的等待記錄窗口叫號把0改成1并寫入CallTime顧客超時(shí)未到則變成2辦結(jié)改成3。QueueNO里的字母前綴來自業(yè)務(wù)類型表的Prefix字段比如 A 開頭的個(gè)人業(yè)務(wù)和 B 開頭的對公業(yè)務(wù)同類業(yè)務(wù)內(nèi)部按三位流水號遞增。T_BusinessType除了存業(yè)務(wù)名稱和前綴還有一個(gè)IsPriority字段表示這個(gè)業(yè)務(wù)類型是否允許優(yōu)先叫號。T_QueueLog則簡單記錄操作的流水誰在什么時(shí)間對哪條隊(duì)列做了什么操作用于事后排查這個(gè)號到底被誰叫過。數(shù)據(jù)模型整體說不上精巧但非常符合叫號業(yè)務(wù)的實(shí)際運(yùn)營邏輯。3.2 取號一個(gè)串行化事務(wù)完成號碼生成取號動(dòng)作的最終落點(diǎn)其實(shí)就是一段查詢最大序號 1再插一條記錄的代碼。但就是這么簡單的邏輯并發(fā)做不好就會出現(xiàn)兩個(gè)顧客取到相同號碼。服務(wù)端Core/TakeNumberHandler.cs里的實(shí)現(xiàn)用了Serializable隔離級別的事務(wù)把取最大值和插入記錄兩件事鎖在同一條鏈路上執(zhí)行/// summary取號核心邏輯生成排隊(duì)號碼并寫入數(shù)據(jù)庫/summary public TicketResult TakeNumber(int businessTypeId) { using (SqlConnection conn DB.CreateConnection()) using (SqlTransaction tx conn.BeginTransaction(IsolationLevel.Serializable)) { // 在事務(wù)內(nèi)查詢該業(yè)務(wù)類型當(dāng)天已存在的最大序號 // 加上 UPDLOCK讓兩個(gè)并發(fā)取號請求在這里排隊(duì)等待而不是同時(shí)讀到同一個(gè)值 SqlCommand cmd new SqlCommand( SELECT ISNULL(MAX(Seq), 0) AS MaxSeq FROM T_QueueInfo WITH (UPDLOCK) WHERE BusinessTypeId bt AND CreateTime today, conn, tx); cmd.Parameters.AddWithValue(bt, businessTypeId); cmd.Parameters.AddWithValue(today, DateTime.Today); int maxSeq (int)cmd.ExecuteScalar(); int newSeq maxSeq 1; // 組合叫號號碼業(yè)務(wù)前綴 三位流水號例如 A012 string prefix GetPrefix(businessTypeId); string queueNo ${prefix}{newSeq:D3}; // 小票流水號用時(shí)間戳生成精確到毫秒用于后續(xù)追溯和預(yù)約核銷 string tokenNo DateTime.Now.ToString(yyyyMMddHHmmssfff); // 插入排隊(duì)記錄Status 默認(rèn) 0 表示等待中 SqlCommand ins new SqlCommand( INSERT INTO T_QueueInfo(QueueNO, TokenNO, BusinessTypeId, Status, CreateTime) VALUES(qno, tno, bt, 0, now), conn, tx); ins.Parameters.AddWithValue(qno, queueNo); ins.Parameters.AddWithValue(tno, tokenNo); ins.Parameters.AddWithValue(bt, businessTypeId); ins.Parameters.AddWithValue(now, DateTime.Now); ins.ExecuteNonQuery(); tx.Commit(); // 返回號碼和當(dāng)前等待人數(shù)給取號端小票打印使用 return new TicketResult(queueNo, GetWaitCount(businessTypeId)); } }這段代碼里有兩個(gè)值得抄走的細(xì)節(jié)。第一個(gè)是WITH (UPDLOCK)它讓并發(fā)取號的多個(gè)事務(wù)在MAX(Seq)查詢處排隊(duì)避免兩個(gè)請求同時(shí)讀到同一個(gè)maxSeq后各自 1 導(dǎo)致號碼重復(fù)。第二個(gè)是CreateTime today這個(gè)條件它保證了流水號只按當(dāng)天累計(jì)第二天取號會重新從 1 開始編號這是叫號業(yè)務(wù)里默認(rèn)的業(yè)務(wù)規(guī)則。GetWaitCount在事務(wù)內(nèi)部執(zhí)行也很重要它查詢當(dāng)前還在等待中的記錄數(shù)這個(gè)數(shù)字會打印在小票上告訴顧客前面還有 X 人。如果把它放到事務(wù)外面取號剛結(jié)束還沒提交事務(wù)時(shí)等待人數(shù)就會少算自己這一個(gè)雖然差別不大但總歸是數(shù)據(jù)一致性問題。3.3 叫號、過號與重呼狀態(tài)機(jī)是怎么轉(zhuǎn)起來的窗口端按下呼叫下一個(gè)服務(wù)端干的活本質(zhì)上是把隊(duì)列里最早一條Status0的記錄改成1然后廣播給大屏。源碼里CallNext的實(shí)現(xiàn)沒有用復(fù)雜的存儲過程而是靠SELECT UPDLOCK先把候選行鎖住再更新/// summary窗口叫號從等待隊(duì)列里取出最早的一條記錄更新狀態(tài)并推送給大屏/summary public CallResult CallNext(int windowId, int businessTypeId) { string queueNo null; using (SqlConnection conn DB.CreateConnection()) using (SqlTransaction tx conn.BeginTransaction()) { // 鎖定最早一條等待中的記錄READPAST 讓并發(fā)的叫號請求直接跳過被鎖的行避免互相阻塞 SqlCommand select new SqlCommand( SELECT TOP 1 QueueNO FROM T_QueueInfo WITH (UPDLOCK, READPAST) WHERE Status 0 AND BusinessTypeId bt ORDER BY CreateTime, conn, tx); select.Parameters.AddWithValue(bt, businessTypeId); queueNo select.ExecuteScalar() as string; if (queueNo null) { tx.Rollback(); return new CallResult { Success false, Message 當(dāng)前無等待號碼 }; } // 把這條記錄狀態(tài)置為“已叫號”并登記窗口和叫號時(shí)間 SqlCommand update new SqlCommand( UPDATE T_QueueInfo SET Status 1, WindowId win, CallTime now WHERE QueueNO qno AND Status 0, conn, tx); update.Parameters.AddWithValue(win, windowId); update.Parameters.AddWithValue(qno, queueNo); update.Parameters.AddWithValue(now, DateTime.Now); update.ExecuteNonQuery(); tx.Commit(); } // 通知大屏端和語音端顯示叫號信息這一步必須放在事務(wù)提交之后 ScreenBus.Broadcast(SVR_CALL_NOTIFY, new { QueueNO queueNo, WindowNO GetWindowNo(windowId) }); return new CallResult { Success true, QueueNo queueNo }; }對READPAST這個(gè)提示需要多做一句說明多個(gè)窗口同時(shí)按呼叫下一個(gè)時(shí)第一個(gè)事務(wù)鎖住了TOP 1的記錄第二個(gè)叫號事務(wù)如果不加READPAST就會一直等第一個(gè)事務(wù)提交才能繼續(xù)掃描導(dǎo)致窗口 2 的叫號按鈕轉(zhuǎn)圈。加了這個(gè)提示后第二個(gè)事務(wù)直接跳過被鎖住的行去取下一條等待記錄兩個(gè)窗口可以同時(shí)各叫各的號互不干擾。這是多窗口叫號場景下最容易忽略的一個(gè)病根。過號邏輯則是掛在服務(wù)端的一個(gè)后臺定時(shí)器上每隔 30 秒掃一次把已經(jīng)叫號但超過 3 分鐘沒來柜臺辦理的號碼置為2已過號并同步推一條消息給大屏讓它從正在叫號區(qū)域移除-- 過號掃描把叫號后超過 OverTime 秒仍未辦理的號碼置為過號狀態(tài) UPDATE T_QueueInfo SET Status 2 WHERE Status 1 AND DATEDIFF(SECOND, CallTime, GETDATE()) 180重呼的邏輯則簡單得多窗口端對一條Status2的過號記錄點(diǎn)重呼服務(wù)端把它從2改回1并重新廣播一次叫號通知。狀態(tài)機(jī)總共就四條邊等待到叫號、叫號到完成、叫號到過號、過號到重呼回叫號理解這四條邊就能看懂整個(gè)系統(tǒng)的流轉(zhuǎn)邏輯。4. 部署運(yùn)行從建庫到聽到第一聲叫號4.1 初始化數(shù)據(jù)庫一條命令把庫建好把源碼拉到本地后第一步不是開 Visual Studio 編譯而是先把數(shù)據(jù)庫準(zhǔn)備好。打開DbScript目錄下的QueueDB.sql里面已經(jīng)寫好了建庫、建表、插入基礎(chǔ)業(yè)務(wù)類型和窗口數(shù)據(jù)的完整腳本。用 SQL Server Management Studio 連上本地?cái)?shù)據(jù)庫實(shí)例直接執(zhí)行這個(gè)腳本即可腳本末尾會插入常見的業(yè)務(wù)類型數(shù)據(jù)和 1 到 8 號窗口數(shù)據(jù)。需要注意的是腳本使用的 SQL 語法只依賴基礎(chǔ)功能2008 R2 及以上版本的 SQL Server 都能跑。執(zhí)行完成后可以驗(yàn)證一下四張表是否都建出來了-- 檢查核心表是否創(chuàng)建成功 SELECT name FROM sys.tables WHERE name IN (T_BusinessType,T_WindowInfo,T_QueueInfo,T_QueueLog);成功后T_BusinessType里應(yīng)該能看到個(gè)人業(yè)務(wù) A、對公業(yè)務(wù) B兩條初始數(shù)據(jù)。如果想改業(yè)務(wù)名稱或加前綴直接在這里改就行但注意前綴長度最好保持 1 個(gè)字母否則QueueNO的字段長度需要相應(yīng)調(diào)整。4.2 配置文件與啟動(dòng)順序數(shù)據(jù)庫就緒后按順序配置四個(gè)程序的連接信息。服務(wù)端的app.config里有兩個(gè)關(guān)鍵配置段connectionStrings里的QueueDB連接字符串以及appSettings里的監(jiān)聽端口和過號時(shí)間configuration connectionStrings !-- 換成實(shí)際部署環(huán)境的數(shù)據(jù)庫地址、賬號密碼 -- add nameQueueDB connectionStringServer127.0.0.1;DatabaseQueueSys;User Idsa;Password123456;Poolingtrue;Min Pool Size5/ /connectionStrings appSettings !-- TCP 監(jiān)聽端口所有客戶端都通過這個(gè)端口連接服務(wù)端 -- add keyListenPort value9100 / !-- 過號超時(shí)時(shí)間單位秒超過這個(gè)時(shí)間未辦理自動(dòng)置為過號 -- add keyOverTime value180 / /appSettings /configuration大屏端、窗口端、取號端的配置則簡單很多只需要告訴程序服務(wù)端在哪appSettings !-- 服務(wù)端所在機(jī)器的 IP局域網(wǎng)部署時(shí)填服務(wù)端電腦的內(nèi)網(wǎng)地址 -- add keyServerIP value127.0.0.1 / add keyServerPort value9100 / !-- 窗口端專屬配置標(biāo)識當(dāng)前程序是幾號窗口 -- add keyWindowId value1 / add keyWindowName value綜合窗口1號 / /appSettings啟動(dòng)順序有講究先啟動(dòng)服務(wù)端再啟動(dòng)大屏端和窗口端最后啟動(dòng)取號端。服務(wù)端啟動(dòng)后監(jiān)聽 9100 端口各客戶端啟動(dòng)時(shí)會發(fā)起 Socket 連接并注冊自己的身份。窗口端啟動(dòng)時(shí)會自動(dòng)把窗口狀態(tài)置為空閑大屏端啟動(dòng)后會向服務(wù)端索要一次當(dāng)前隊(duì)列快照把已經(jīng)叫號但還沒辦結(jié)的號碼恢復(fù)到屏幕上顯示出來。如果反過來先啟動(dòng)客戶端再啟動(dòng)服務(wù)端客戶端會進(jìn)入斷線重試狀態(tài)每 3 秒嘗試重連一次倒也能自動(dòng)恢復(fù)。4.3 驗(yàn)收流程模擬一次完整的取號叫號全部啟動(dòng)完成后可以用一個(gè)最簡單的方式驗(yàn)證整個(gè)系統(tǒng)是否跑通手動(dòng)造一條取號請求。如果沒有實(shí)體取號機(jī)和小票打印機(jī)可以直接打開取號端程序界面上會顯示業(yè)務(wù)類型按鈕點(diǎn)擊個(gè)人業(yè)務(wù)按鈕程序會向服務(wù)端發(fā)送TERM_TAKE_NUMBER請求服務(wù)端返回新生成的號碼。此時(shí)觀察兩點(diǎn)取號端界面應(yīng)顯示您的號碼是 A001前面還有 0 人服務(wù)端的日志窗口或日志文件里應(yīng)打印一條插入排隊(duì)記錄的操作記錄。然后在窗口端點(diǎn)擊呼叫下一個(gè)服務(wù)端日志會打印A001 分配至窗口 1大屏端界面應(yīng)隨即顯示請 A001 到 1 號窗口語音模塊同時(shí)播報(bào)一遍。最后在窗口端點(diǎn)擊辦結(jié)服務(wù)端把記錄狀態(tài)置為3大屏端把這條叫號信息從顯示區(qū)移除。這四步走通整個(gè)系統(tǒng)的核心鏈路就驗(yàn)證完成了。如果在大屏端聽不到語音播報(bào)先檢查系統(tǒng)是否安裝了 TTS 語音包源碼里語音模塊用的是 Windows 自帶的語音合成接口精簡版系統(tǒng)可能缺失語音引擎但不影響業(yè)務(wù)鏈路。這一步很多人容易誤判為代碼問題其實(shí)環(huán)境問題占多數(shù)。5. 避坑指南排隊(duì)機(jī)項(xiàng)目部署里最常見的五個(gè)翻車現(xiàn)場5.1 窗口端連不上服務(wù)端提示遠(yuǎn)程主機(jī)強(qiáng)迫關(guān)閉了一個(gè)現(xiàn)有的連接這個(gè)現(xiàn)象多發(fā)生在服務(wù)端程序跑得好好的、窗口端卻反復(fù)連接失敗的時(shí)候。最常見的原因就兩個(gè)一是服務(wù)端只監(jiān)聽了本機(jī)回環(huán)地址而不是0.0.0.0導(dǎo)致局域網(wǎng)內(nèi)其他機(jī)器根本連不進(jìn)來二是 Windows 防火墻默認(rèn)攔截了 9100 端口的入站連接。排查時(shí)先在窗口端所在機(jī)器用telnet 服務(wù)端IP 9100測一下端口通不通不通就去服務(wù)端執(zhí)行一條放行命令netsh advfirewall firewall add rule nameQueueServer dirin actionallow protocolTCP localport9100另外一種隱蔽的原因是服務(wù)端監(jiān)聽了 IPV6 地址而客戶端用 IPv4 解析兩端沒有配到同一個(gè)協(xié)議棧上。處理辦法是確保服務(wù)端監(jiān)聽時(shí)IPAddress.Any而不是顯式指定具體 IP。5.2 叫號后大屏要等兩秒才刷新像卡住了一樣如果你接手時(shí)大屏端還是輪詢數(shù)據(jù)庫的實(shí)現(xiàn)那這個(gè)現(xiàn)象幾乎是必現(xiàn)的。大屏端每 2 秒查一次T_QueueInfo里有沒有新叫號的記錄查到才刷新界面體驗(yàn)就是叫號慢半拍。其實(shí)窗口端點(diǎn)了叫號數(shù)據(jù)一毫秒內(nèi)就寫進(jìn)數(shù)據(jù)庫了慢的是輪詢周期。解決思路是把大屏端改成 Socket 推送模式。服務(wù)端在CallNext和重呼完成之后直接把SVR_CALL_NOTIFY主動(dòng)推送給所有已注冊的 Screen 端大屏收到消息立刻刷新延遲從輪詢周期縮短到網(wǎng)絡(luò)時(shí)延。這個(gè)改動(dòng)需要?jiǎng)臃?wù)端的ScreenBus.Broadcast方法和客戶端的消息接收處理如果手頭這份源碼已經(jīng)是大屏主動(dòng)推送的版本就直接跳過這條。5.3 兩個(gè)顧客同時(shí)取號拿到了同一個(gè)號碼這在數(shù)據(jù)庫開發(fā)里屬于并發(fā)經(jīng)典的翻車現(xiàn)場。取號邏輯如果用先查詢MAX(Seq)再在代碼里 1最后 INSERT的老寫法兩個(gè)請求并發(fā)執(zhí)行時(shí)可能同時(shí)讀到maxSeq5各自插一條A006進(jìn)庫。事務(wù)內(nèi)查詢不加鎖或者隔離級別設(shè)成READ COMMITTED都擋不住這個(gè)問題。正確的修法是給取號邏輯的事務(wù)加上IsolationLevel.Serializable或者可重復(fù)讀并且在查詢語句里帶上WITH (UPDLOCK)。另一種方案是給T_QueueInfo的(BusinessTypeId, QueueNO)建唯一索引插入時(shí)捕獲重復(fù)鍵沖突然后重試一次。兩者可以共存但事務(wù)加鎖是更符合叫號業(yè)務(wù)的做法重試邏輯只能算后悔藥。5.4 系統(tǒng)跑了兩天數(shù)據(jù)庫連接池爆滿服務(wù)端開始報(bào)連接池已達(dá)到最大大小這個(gè)坑大多不是源碼本身的問題而是二次開發(fā)時(shí)到處new SqlConnection忘關(guān)導(dǎo)致的。叫號這類服務(wù)端程序長時(shí)間運(yùn)行任何一個(gè)請求路徑上泄漏一條連接半天就能把默認(rèn) 100 條連接池耗盡。排查方法很直接在 SQL Server 里執(zhí)行SELECT * FROM sys.dm_exec_sessions WHERE login_namesa看會話數(shù)是不是只增不減是的話就是代碼里沒用using釋放連接。建議重構(gòu)數(shù)據(jù)訪問層統(tǒng)一由一個(gè)DBHelper管理連接創(chuàng)建和關(guān)閉每次取連接都走using (var conn DB.CreateConnection())的寫法確保任何異常路徑都不會泄漏連接。5.5 服務(wù)端升級重啟后隊(duì)列里已叫號的號碼全部卡死服務(wù)端重啟一小會兒重新連上的大屏上那些叫到一半的號碼狀態(tài)全是已叫號但顧客早就被晾在一邊了。原因是隊(duì)列狀態(tài)存在數(shù)據(jù)庫里但叫號通知只存在于大屏的內(nèi)存中服務(wù)端一重啟沒有哪塊邏輯去接管這些半途狀態(tài)。解決辦法是給服務(wù)端寫一個(gè)啟動(dòng)恢復(fù)邏輯進(jìn)程起來后先把所有Status1且CallTime停留在 30 分鐘之前未辦結(jié)的記錄重置為0或直接置為過號2然后向所有大屏端廣播一次SVR_SCREEN_SNAP隊(duì)列快照讓屏幕恢復(fù)到正確的隊(duì)列狀態(tài)。這段邏輯要放在服務(wù)端開始接收新請求之前執(zhí)行否則恢復(fù)的同時(shí)又來新叫號狀態(tài)又會亂掉。6. 二次開發(fā)給叫號系統(tǒng)加預(yù)約取號和微信提醒如果讓我在這個(gè)項(xiàng)目上做第一個(gè)改造我大概率會先做預(yù)約簽到這個(gè)功能。現(xiàn)在銀行網(wǎng)點(diǎn)和醫(yī)院分診臺普遍支持線上預(yù)約后到現(xiàn)場取號核心訴求是讓預(yù)約過的顧客到了現(xiàn)場能優(yōu)先叫號。落在代碼上需要改三個(gè)點(diǎn)T_QueueInfo表增加SourceType字段區(qū)分預(yù)約和現(xiàn)場取號端加一個(gè)輸入預(yù)約流水號簽到的入口以及改叫號調(diào)度算法讓預(yù)約號優(yōu)先出隊(duì)。/// summary預(yù)約優(yōu)先的叫號調(diào)度先取預(yù)約等待號再取現(xiàn)場號/summary private string PickNextQueueNo(int businessTypeId) { // 優(yōu)先把 SourceType1 且狀態(tài)為等待中的預(yù)約號叫出去 string next GetNextBySource(businessTypeId, sourceType: 1); // 預(yù)約隊(duì)列取空了才輪到現(xiàn)場號 if (next null) next GetNextBySource(businessTypeId, sourceType: 0); return next; }微信提醒的改造相對獨(dú)立可以在服務(wù)端加一個(gè)后臺定時(shí)器掃描Status1的已叫號記錄超過一分鐘就調(diào)一次第三方 HTTP 接口把您的號碼已叫號請前往 3 號窗口推給公眾號模板消息。這一塊完全不碰現(xiàn)有業(yè)務(wù)鏈路適合作為練習(xí)讀源碼的切入點(diǎn)。這套源碼我斷斷續(xù)續(xù)拆過兩遍第一遍只顧著把取號邏輯跑通直到現(xiàn)場被兩個(gè)窗口同時(shí)叫號互相卡死的問題折磨了一下午才回頭把UPDLOCK, READPAST的語義吃透。從那以后我每接到一個(gè)消息分發(fā)類項(xiàng)目都會強(qiáng)制自己先畫出狀態(tài)流轉(zhuǎn)圖和消息時(shí)序圖再動(dòng)手把哪個(gè)事務(wù)該鎖住哪一行、哪條廣播該放在提交之后先想明白?？此撇黄鹧鄣呐抨?duì)叫號里頭的并發(fā)和數(shù)據(jù)一致性考量一點(diǎn)不比高并發(fā)秒殺系統(tǒng)少希望這份拆解能幫你在跑通和改造的全程少踩幾個(gè)坑。本文還有配套的精品資源點(diǎn)擊獲取