高并发下NIO socket消息超时机制的探讨

?????去年参与项目的两个模块均采用socket长连接+心跳机制，模块A：2000/秒（日高峰，持续3小时吧），春节高峰20000+，去年从春节前的28号开始出现暴涨超时严重，29号瘫掉了；模块B基本上没啥压力,零星的一月几万而已；

????

????? 探讨下其中遇到的问题抛砖引玉，共同提高，讨论结束，将单纯的通信，超时处理整理成可运行的demo供大家参考。

?

??????应用场景?????????

????? 其中模块A作为客户端接收服务端推送消息，模块A连接绑定至七个服务器端，所以采用了多线程，服务端3秒超时，超时返回影响业务。

????? 模块B作为服务端出现：服务端和客户端可以双方相互发送请求消息，服务端支持多客户端同时长连接，客户端A发送的消息响应返回到A，不能出现客户端A消息的响应返回到B的情况。每个客户端的超时时间不确定通常在3-5秒之间；

?

???? 问题讨论：

???? 我们的俩个模块都涉及socket通信判断消息超时的机制，如何在控制空间复杂度和时间复杂度的同时解决消息超时问题；

?

????? 目前方案：

??????目前采用的解决方案消息发送前CurrentHashMap.put(seqNo,message)，待消息返回直接CurrentHashMap.remove（sqpNo），针对每个连接启动一个扫描线程，定时扫描缓存CurrentHashMap，清除过期消息；

????? 目前我们的客户端只有2个，分别发送业务消息，资源消息，如果客户端继续增加，显然每个链路建立一个扫描线程定时扫描浪费资源，毕竟超时的消息很少，除非节假日的业务高峰；???????????

?

???? 对于为何不采用apache mina等高性能的socket框架，历史遗留问题，我也很纳闷为何设计之处未考虑采用；

????

对于超时处理，一个超时线程来处理，数据结构我建议是一个linkedlist,一个hashmap，linkedlist存放流水号，hashmap里存放key=流水号，value=请求对象，利用linkedlist的FIFO特性，如果第一个不超时，后面的就不需要循环去判断请求时间了
dwangel 写道
只要开一个线程，监测这个HashMap里长时间没接到消息(currentMillis-lastTick>XXX)的连接，再切断就是了。

linkedHashMap结合了2者特性，但是不能for循环去remove
如果有更好的办法，多讨论。。
13 楼 Kanepan 2010-09-16 这么好的帖子，不能沉下去