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