業務中需要應用到Websocket長連接進行數據傳輸，由於服務使用的是Zuul1.0版本，對ws協議支持較弱，後續嘗試使用了 spring-boot-starter-websocket 來完成的。關於怎麽集成的話網上有非常多的文章了，我就不多費口舌了。
我們目前實現的功能是可以通過WebSocket調用接口發送埋點，另外還需要監聽用戶離開的事件為這個埋點畫上壹個終止訪問時間。目前測試下場景有：
前4點觸發了任意操作，服務端都會監聽到 DISCONNECT 離開事件。但是第5點直接斷網， 服務端竟然是無感知的，這個時候產生的問題就是客戶斷網了，服務端是認為在線的，如果不重新聯網登錄的話，那麽這個用戶將會壹直壹直在線，埋點會壹直計算。完了個蛋~
至於為什麽斷網之後，ws會認為他是在線的， 可能管道打開了之後由於斷網導致斷開時間發送不出去吧。
我目前能夠想到比較簡單的辦法就是： 心跳續約
捋清了思路，大概就知道如何做了。
然後特意看了下 spring-boot-starter-websocket 的源碼，發現其實他有提供此功能。
先說下如何實現:
我們是在在實現了 DelegatingWebSocketMessageBrokerConfiguration 的配置類中重寫 configureMessageBroker 方法。
比較關鍵就是 setTaskScheduler 和 setHeartbeatValue 壹個負責調度、壹個負責配置間隔。
這倆要麽都填要麽都不填。
配置了這倆參數之後，服務啟動的時候會觸發壹個 HeartbeatTask 線程來專門維持心跳。
我們可以看看他的流程是如何運轉的。
核心任務調度類: org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.HeartbeatTask
服務端在啟動的時候 SimpleBrokerMessageHandler 在初始化完成之後會回調 start 的方法，然而他會觸發壹個 startInternal 開始調度任務，判斷依據就是有沒有配置 TaskScheduler ( 對應的就是配置類中的setTaskScheduler )，壹旦啟動之後，會根據妳給的心跳數組 serverHeartbeat ，來選擇調度時間。
org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler
檢測心跳、超過間隔則剔除、並且定期回寫心跳給客戶端。
還有壹點需要註意的是讀的間隔時間：
假設用戶網絡不好，心跳漏發了壹次，這個時候如果按照本次的邏輯而言，該用戶的最後心跳時間肯定會超時。而它的做法是， 將設定的讀超時時間 3 ，就相當於有3次機會*。
這個在創建session的時候 SessionInfo 裏面就已經做好了處理:
org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.SessionInfo#SessionInfo
所以這個時候，妳可能需要根據業務能夠接受的時長去配置，也別忘了這個事。
還有很關鍵的壹點就是讓客戶端的心跳發送間隔和服務端盡可能保持壹致，不然有可能出現莫名其妙的下線情況，盡可能還是在這種地方加好日誌。
好了，希望在遇到斷網問題的時候，能夠幫助到妳。
如果有疑問請留言，我會盡快答復。