直接用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，上述例子可能存在单点故障，可以通过改变上层机器数解决单点故障