年初時3月開始參與消息服務器開發，3月3日開始提交代碼，由於是挺久前寫的代碼，所以可能記得不是很完整，簡單交代下背景開始寫。
之所以開發消息服務器，是因爲目前電子病歷生產業務服務器爲微軟COM+中間件，主要有以下缺點：
1. 無法及時瞭解電子病歷客戶端登錄信息。
2. 無法提供各個客戶端之間已經服務端和客戶端之間進行消息通訊。
3. 不能提供真正的服務器負載均衡功能，浪費副服務器硬件資源。
在生產環境的基礎上增加日誌業務處理性能壓力可能會影響系統性能。故開發以TCP/IP長連接
方式（無線路由UDP會出現問題）實現的消息服務器以處理這些問題。
在項目中我主要負責在線用戶管理，功能日誌管理，及其他模塊部分BUG修復。
在線用戶主要包括以下功能：
1. 提供多種過濾實時統計查詢在線用戶。
2. 查看或修改用戶服務器（COM+）信息，除可手工修改外，還可動態（用戶組件超時時）修改服務器信息。
3. 向在線用戶發送系統消息，如：升級消息，關閉系統消息等等。
功能日誌管理主要包括以下功能：
1. 服務端（TCP）實時查詢用戶操作。
2. 用戶離線後同步操作至服務器（COM+）。
具體實現就不細說了，主要說說開發中遇到的問題（忘得差不多了，只寫兩個）：
1. 客戶端非優雅斷開情況下，服務端用戶在線，但是實際上用戶已斷開，這種情況其實在服務器中都會存在，如客戶端直接插拔網線就會造成這種情形，究其原因在於 四次揮手，具體不細說。當初並沒有這塊的經驗，在現場實際生產環境中，發現服務器連續打開一週左右，巔峯連接數明顯偏高（醫院環境下，機器700+臺應爲巔峯），當時達到了1200+臺，且仍處於上升階段，在本地環境中反覆校驗中重現了此問題，查詢了很多資料後發現 無論多麼合理的設計，在現場複雜的生產環境下都會出現殭屍鏈接，也就是實際斷開，但是服務端並沒有斷開的情況。所以需要 心跳檢測機制，引入心跳檢測後，殭屍鏈接消失。這裏的心跳檢測指的是，服務端定時向在線的客戶端發送消息，以收到的心跳包回覆判定用戶是否已斷開。或者在大數據鏈接時，適時的斷開有些不活躍的用戶。實現方式主要有兩種：一種是TCP所自帶的KEEPALIVE，一種是自己定時發送心跳包，第一種網上的評價很極端，一方說極限環境下會有問題，一方說網遊服務器用後效果很好，這裏不深究，採用第二種發送，發送小包到客戶端。這邊其實還可以商榷，如果客戶端與服務端的通信相對活躍，完全可以在服務端每一次接收到客戶端的包後記錄服務端時間，定時的去檢測客戶端最後一次發送到服務端的包的時間，然後刪除超過閾值的失活用戶。
2. 客戶端鏈路斷開而內存數據庫中客戶端未刪除的情況，客戶端斷開實際上包含客戶端發送離線協議給服務端（TCP）解析，解析後刪除內存數據庫中關於客戶端的信息，然後鏈路斷開，但是極限環境下可能存在一種情況，即客戶端鏈路斷開優先於服務端處理離線消息，導致鏈路已斷開，但是內存數據庫中客戶端數據並沒有刪除。這種情況引入隊列（具體實現有點忘），也就是說將客戶端的離線協議消息發送和鏈路斷開的消息放在一個線程的一個隊列中，當客戶端發送離線消息時，只記錄離線時間，不做任何具體的操作，在鏈路斷開後再進行收尾工作（刪除用戶信息，同步用戶信息到服務器（com））。