故障排查：是什麼 致使了客戶端批量心跳超時掉線

       心跳超時指的是：針對某個在線的客戶端（TCP鏈接），ESFramework服務端在指定的時間內，沒有收到來自該客戶端的任何消息，則認爲該客戶端已經掉線。

       爲何須要心跳機制了？由於針對某些客戶端掉線（多是由於網絡斷開、或客戶端程序退出），服務端不能當即感覺到（有的可能須要過很長的時間才能感覺到），因此，須要引入心跳機制，讓服務端儘量早地發現客戶端已經不在線了。關於心跳機制，更詳細的介紹能夠參見這裏。

        若是發生了不少客戶端批量心跳超時掉線的狀況，就說明服務端在過去的某段時間內，從未收到來自這些客戶端的任何心跳消息。一般有3種可能性致使該狀況發生：

1.CPU或內存使用率太高

       在該狀況發生時，觀察一下服務端進程的CPU和內存是否有異常。

       好比，當CPU持續在100%時，就有可能致使接收數據的操做被中止。

2.處理某些信息所花費的時間過長

        若是服務端的信息處理模型設定的是IocpDirectly，那麼依據IocpDirectly的原理，當處理某個信息所花費的時間超過了服務端設定的心跳超時的時間，服務端就會將對應的客戶端誤判爲心跳超時掉線。

        假設是該緣由致使的心跳超時，則對應的解決方案有：

（1）找出那些處理很是耗時的信息，進行優化理，加快處理速度。

（2）將超時時間間隔設定位一個更大的值或關閉心跳檢測。

（3）將信息處理修改成異步模式。

（4）將服務端信息處理模型修改成TaskQueue模式，這樣就徹底避免了因爲信息處理時間過長致使誤判的狀況。

        很顯然，方案（1）是最好的也是根本性的解決方案。 

3.服務器網絡拓撲結構、防火牆、路由器、網絡安全監控等相關軟硬件

        若是排除了前面的可能性（好比，即便改爲了TaskQueue模式，批量掉線仍然發生），那麼，幾乎就只剩下一個可能：服務端在心跳超時時間間隔內未收到來自這些客戶端的任何消息。極可能來自客戶端的消息被防火牆、路由器、或某些網絡徹底監控的相關軟硬件給擋住了。

        此時，須要專業的運維人員或網管人員參與進來，協助排查問題，好比：

（1）在服務器上執行netstat命令，查看目標端口的相關狀態信息。

（2）在服務器上執行抓包工具，監測目標端口上是否有數據從客戶端過來。

（3）分析服務器的網絡拓撲結構，並以服務器爲中心，依次向外檢查防火牆、路由器、網絡安全監控等相關軟硬件等的設定，並進行鍼對性的排查測試。

 

      通過以上的排查分析，應該均可以找到問題的根源所在，若是仍是沒有結果，能夠給我留言，咱們一塊兒討論下啊。