高并发下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框架，历史遗留问题，我也很纳闷为何设计之处未考虑采用；
????
