当服务器Accept一个新的socket之后会对这个socket进行封装成为一个connection(当然是自定义了) 。之后的处理都会交给这个connection负责。由于socket发送的数据存在分包、黏包问题connection接收模块注定了要使用接收队列。当然这个所谓的接受队列并没有大家想象的这么深奥大致的代码结构如下publicclassSocketReceiveQueue{privateQueueISocketReceivePackagequeuenull;privateMemoryStream receiveBuffernull;}即一个queue的接收队列一个stream。处理逻辑a. 接收到数据压入receiveBufferb. 从receiveBuffer读取数据、获取协议包ISocketReceivePackage这里可能会有多个也可能一个也没有。c. 当接收完毕后协议包再从queue出队列交给注册的协议处理handler处理。到目前为止整块接收逻辑并没有涉及具体的业务、也绝对不应该涉及具体的业务。唯一要额外注意的就是接收包的长度问题即协议包声明的length是否过大。这里要注意由于整个接收模块没有涉及到具体的业务逻辑也就不应该在这里对任何的输入进行检测非法攻击、频率等代码上就是以最快速度解析完协议包然后丢给上层handler分析。-------------------客户端请求性能分析-------------------当协议包来到了与业务相关的Handler之后我们开始进行性能检测。首先是请求频率使用如下公式requestInterval(requestInterval*requestTimesinterval)/(requestTimes1)计算得到的requestInterval就是客户端的请求频率。 数学上也很简单就是一个类似f(x) af(x)b的迭代算法。这个算法的特定当然就是性能高我只需要记录用户当前请求时间、请求累计次数之后就能完全监控了用户的请求性能。此外还需要记录顾客的错误次数。从设计理论上来说客户传输过来的数据不应该有错除非代码出错。当然如果在值类型之间转换出现的问题算是错误的话用户正常输入了错误的数值这个不算入错误。这个错误值是需要记录在数据库里面一旦发现错误值过大则直接封这个IP了。还需要说明的是在服务器一定有一个触发器每x秒会遍历一次所有的connection一旦发现有长时间无请求的空连接要主动踢出。-------------------socket服务端发送模块设计-------------------当服务器处理完数据后需要将处理结果回复给客户端。如果使用简单的设计思路即直接压入socket发送性能是非常的低的因此socket的发送必定需要使用发送队列。使用发送队列的优势在于a. 当服务器内部需要发送的数据激增的时候通过压入发送队列能够减轻IO的处理压力。很多时候我们会发现整个服务器的性能瓶颈就在IO的处理上收发 而不是服务器的数据库操作等。因此设计上就要以减轻IO处理为目标。b. 使用发送队列能够把多个回复数据包合并一次发送极大减轻了IO的压力。发送队列的结构也就是一个Queue大致的设计如下代码publicclassSendMessageQueueController{QueueSocketConnectionqueue;}publicclassSocketConnection{privateSocketReceiveQueue receiveQueue;//接收队列privateSocketSendQueue sendQueue;//发送队列}publicclassSocketSendQueue{privateQueueISocketSendPackagequeue;//发送协议集合}代码逻辑如下a. 把需要发送的协议包压入当前SocketSendQueue.b. 判断SocketConnection是否已经存在在SendMessageQueueController如果不存在则入列如果存在则返回。c. SendMessageQueueController每隔x毫秒检查一次发送队列如果发现有数据则进入while循环直到所有SocketConnection出列并发送所有的数据。之后再进入等待。d. 所谓包合并发送就是把多个协议包一次写入发送的Stream里面然后让socket发送。这块的设计问题主要集中在线程冲突需要在关键地方加几把锁否则就容易出现线程冲突了。------------------后记------------------本文介绍的方法并不是最好的方法我也相信业界有更加成熟的思路。不过我文中列举的一些设计思路至少我用起来还是能够满足现有需求的。
