Server(Iocp)的那些烦恼

自G-Socket0.88版开源以来，得到很多朋友的支持。从1.0版本至2.0之前，内核几乎没有改变，经过多处的应用其稳定性和效率表现是相当不错的。这几年的经验总结成一句话：服务器程序不是有了一个好的Iocp通信组件就能玩转的。

 

很多情况下，我们都会遇到下面的问题：

1 致命的锁

又死锁了，怎样高效而又不死锁？是不是使用无锁算法就能解决？

2 无序的数据

为什么服务器接收的数据包会丢包？为什么客户端收到的数据乱序了？

3 野指针

别说多线程了，我都单线程了，为什么还有野指针？

4 低效的IO

为什么CPU使用率这么低，服务器怎么还这么卡？

5 恶劣的网络环境

为什么客户端都已经断线了，服务器端的客户链接数量不是0？

6 该死的客户端

我服务器都是IOCP了，怎么客户端接收的效率还这么低？

7 巨大数据积压

为什么通信模块有这么大的数据积压耗费这么多的内存？

8 莫名的异常

不能实时调式不能24小时监视，怎么分析这些服务程序异常？

 

下面解决问题的提示点，有些只有“资深”才能发现了：

1不是使用无锁算法就能解决死锁问题，而是良好的线程架构体系。

2 多线性并不是完全的多线程，它是针对多个连接而言，不是针对单个的连接对象，起码在粘包处理和数据发送这方面。

3 复杂的服务端程序有很多队列，必须要保证所有网络和用户请求等事件能被有序（按发生的事件先后顺序）被处理！

4 你是不是在逻辑线程里面直接IO操作了？

5 要有应用层面的心跳包，不要完全信任Socket底层的下的心跳机制。

6 你是不是在客户端使用了Window Message Mode的通信组件了，而且在消息事件里面解密处理数据了？

7 但凡是异步通信的都会有Copy和List，要么是接收快处理慢，要么是发送快客户端接收慢，或者客户连接的网络环境恶劣，导致数据队列积压，也就是生产和消费不平衡。

8 除了日志，还是日志，一个再牛X的程序员，也要写完善的日志体系。