一周学习一个架构，百万连接超时处理如何做

业务场景：

如果我们用过一些在线客服系统，常常会遇到这样的问题。如果我们3分钟没有跟客服对话了，那么就会弹出一条消息跟你说，你3分钟没有会话了，已经自动离线了。

首先学习一个东西我们要了解这个东西背后的原因，这种产品逻辑主要有2个好处：

1.减少客户端/用户跟服务器的链接，减少服务的压力。一般我们一个机器也就维护几十万的长连接，很多用户都是咨询完不立马关掉窗口的，如果我们一直保持长连接，很消耗机器的性能。

2.更方便于客服资源的分配，例如一个在线客服可能最多同时接待20个用户，及时地发现不活跃的用户，有利于提高在线客服的接待效率。（万恶的资本家）

方案：

从开发人员的角度看来，这个叫做链接超时。实现这个功能，我们一般有下面几种不同的方案：

1.我们创建一个定时器，用一个map来存储所有的用户最活跃的时间，每隔1秒钟检查所有所有的用户，判断用户上一次活跃的时间距离当前时间是否超过3分钟，如果已经超过3分钟，那么就将这个用户淘汰，标记为不活跃。这种实现的优点是实现简单，逻辑也非常简单，缺点是每次都需要轮询，效率太低。而且在map里面淘汰一个元素，可能会涉及到锁的问题，有一定的并发风险。

2.第二种，我们对每一个用户创建一个定时器，到了对应时间再来检查这个用户是否还是活跃的。虽然我们提升了效率，但是消耗的资源也是巨大的，非常容易把机器拖垮，最不建议采用。

3.第三种

创建1个定时器效率低，每个用户创建1个资源要消耗太大，有没有折衷的方案呢？那就是一批用户创建一个定时器。方案一因为每次都要扫描所有的用户，所以造成很大的浪费，所以我们可以按照用户上一次活跃的时间来做分组，同一个时间点活跃的用户在同一个结点里面，这样子，我们每次扫描的时候，就只须枚举对应时间点的用户了，假设超时时间是3分钟，新算法的计算的量只要原来的一百分十分之一。我们可以再通过环形队列进行优化，可以代码更容易编写，还能减少一些中间状态造成内存浪费。

4.第四种，我们采用客户端上报的方式，跟用户聊天的客户人员每隔一段时间进行上报，告诉服务器哪些用户已经很久没活跃了，可以断开链接了。也可以是用户的客户端或者网页进行上报，检测自身多久没有活跃之后告诉服务器自身已经不活跃了。当然，客户端上报看起来挺不错的，又节省资源又没复杂的算法，但服务端可能会上报失败，例如程序被用户关闭之类的，所以这种方法我们这个更多的是作为优化的手段。

总结：

好了，上述就是我们讲的客服系统一些超时的常用方法，里面提到的环形队列，如果你有兴趣，可以关注我，下次我们再一起讲讲这个东西在各种架构的应用。