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