業務場景：

如果我們用過一些在線客服系統，常常會遇到這樣的問題。如果我們3分鐘沒有跟客服對話了，那麼就會彈出一條消息跟你說，你3分鐘沒有會話了，已經自動離線了。

首先學習一個東西我們要了解這個東西背後的原因，這種産品邏輯主要有2個好處：

1.減少客戶端/用戶跟服務器的鍊接，減少服務的壓力。一般我們一個機器也就維護幾十萬的長連接，很多用戶都是咨詢完不立馬關掉窗口的，如果我們一直保持長連接，很消耗機器的性能。

2.更方便于客服資源的分配，例如一個在線客服可能最多同時接待20個用戶，及時地發現不活躍的用戶，有利于提高在線客服的接待效率。（萬惡的資本家）

方案：

從開發人員的角度看來，這個叫做鍊接超時。實現這個功能，我們一般有下面幾種不同的方案：

1.我們創建一個定時器，用一個map<用戶，最後登錄時間>來存儲所有的用戶最活躍的時間，每隔1秒鐘檢查所有所有的用戶，判斷用戶上一次活躍的時間距離當前時間是否超過3分鐘，如果已經超過3分鐘，那麼就将這個用戶淘汰，标記為不活躍。這種實現的優點是實現簡單，邏輯也非常簡單，缺點是每次都需要輪詢，效率太低。而且在map裡面淘汰一個元素，可能會涉及到鎖的問題，有一定的并發風險。

2.第二種，我們對每一個用戶創建一個定時器，到了對應時間再來檢查這個用戶是否還是活躍的。雖然我們提升了效率，但是消耗的資源也是巨大的，非常容易把機器拖垮，最不建議采用。

3.第三種,創建1個定時器效率低，每個用戶創建1個資源要消耗太大，有沒有折衷的方案呢？那就是一批用戶創建一個定時器。方案一因為每次都要掃描所有的用戶，所以造成很大的浪費，所以我們可以按照用戶上一次活躍的時間來做分組，同一個時間點活躍的用戶在同一個結點裡面，這樣子，我們每次掃描的時候，就隻須枚舉對應時間點的用戶了，假設超時時間是3分鐘，新算法的計算的量隻要原來的一百分十分之一。我們可以再通過環形隊列進行優化，可以代碼更容易編寫，還能減少一些中間狀态造成内存浪費。

4.第四種，我們采用客戶端上報的方式，跟用戶聊天的客戶人員每個一段時間進行上報，告訴服務器哪些用戶已經很久沒活躍了，可以斷開鍊接了。也可以是用戶的客戶端或者網頁進行上報，檢測自身多久沒有活躍之後告訴服務器自身已經不活躍了。當然，客戶端上報看起來挺不錯的，又節省資源又沒複雜的算法，但服務端可能會上報失敗，例如程序被用戶關閉之類的，所以這種方法我們這個更多的是作為優化的手段。

總結：

好了，上述就是我們講的客服系統一些超時的常用方法，裡面提到的環形隊列，如果你有興趣，可以關注我，下次我們再一起講講這個東西在各種架構的應用。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!