直接用TCP 長連接～ 智慧家庭一般 MQTT 協定比較多～～
長連接比輪詢省太多資源了～
單機情況下還是可以實現的，當然，算上資料庫就另說了。

這裡想檢視你對分散式架構的認識，就這個問題應該是想考察你對於服务发现(service discovery)的认识。分布式就是把一个大型项目进行模块化拆分，然后各模块在做集群部署，前端有一个路由服务器来对到达的请求进行分发，把到达的请求路由到能够提供服务的服务端，而哪台服务器能够提供服务这就是服务发现所要做的事情，而在集群环境下能够提供相等服务的服务器肯定不止一台，那到底该由那台服务器对用户的请求进行处理并响应呢？这就又引出了负载均衡，由负载均衡层通过特定的算法来判断应该由那台服务器提供服务，目的就是均匀的把请求分发给各个服务端。服务发现可以了解下Apache的zookeeper或者Netflix的Eureka。微服务这块spring cloud提供了全套的解决方案，还有阿里的dubbo

分散式session管理

我出個簡單一點方案
給設備安裝一個代理進程，設備啟動時啟動該進程，然後由進程主動定時向伺服器上報設備狀態，如果超過一定週期沒上報就認為該設備已經離線

高並發，非同步通訊。 java 的話。 。 。 經典的 netty ？
個人意見，依照目前的單機效能，100k並發單機能撐住，分散式處理不是必選項，當然要是算上資料庫儲存什麼的就另說了。

假如不考慮長連接的話，有個思路利用redis設置一個每個設備上線flag並設置其一個有效時間客戶端每次做上行請求的時候刷新該有效時間每次統計redis在線狀態設備數量就好了這裡關鍵是這個時間的長度怎麼來定因為一直是做後端的不清楚這裡客戶端不活躍的情況下能保持在線多久是否有類似守護進程之類的

把資料存放在redis裡面，存取相對於db快

是我的話,我會這樣做:
新建一個MySQL內存表(ENGINE=MEMORY):
online(user_id, update_time)
用update_time記錄用戶最近訪問時間.
比如可以假設在5分鐘內的用戶都認為在線.

可以分層實現，舉個例子，例如10w台機器，分別向10台機器上報本機狀況，10w台怎麼對應10台，可以透過hash映射的方式，然後這10台機器再把出現故障的機器向一個固定的主機回報情況，大概意思就是10w-->10-->1，上述例子可能有單點故障，可以透過改變上層機器數來解決單點故障