痛苦的epoll+线程池实践 1 程序架构

 
  感谢 《 经验实在太重要了：epoll的一些补充》
  我陷在epoll摸索的泥潭中，没有这个文章，不知道何时才能脱身；

  公司游戏网关原来使用单线程poll，从整体需求来说，支持 4000 在线客户端即可，初步感觉原有架构已足够使用；有瓶颈的话，适当调优即可；
  但是老大拍脑袋决定使用 epoll+线程池，个人又非常想摸索一下 epoll，而且这对提高系统性能有很大帮助，所以何乐而不为呢；

  实践中发现 epoll+线程池 自己摸索就很折腾，再加上把业务逻辑做到网关（每个连接绑定系统唯一UserName、如有重复登录需踢掉旧连接、连接

断开需通知到在线服务器），整个过程充满艰辛；
  一开始精力都耗费在多线程的业务逻辑上，如果程序从头写起，估计思路会清晰点；

  程序整体架构，分三块： 1、主线程 epoll；  2、线程池业务处理；  3、异步关闭连接线程
  主要数据结构：1、连接会话 ConnSession，包含 fd, 绑定username，数据缓存； 2、fd可读队列 3、连接会话ConnSession 关闭队列

  主线程：负责响应 epoll事件，将可读的fd 写到队列；
  线程池业务处理：阻塞在可读fd队列；有可读fd取出，根据fd 找到相应的 ConnSession，并做读取数据到ConnSession数据缓存，同时找到需转发

的ConnSession，转发；
  标志ConnSession 的关闭：任何有异常的连接，不能直接关闭及delete相应的ConnSession实例（因为线程池并发查找、处理ConnSession)；应先从

epoll清除该连接fd，同时将该ConnSession标识为即将关闭，并入到连接会话ConnSession 关闭队列；
  异步关闭连接线程：阻塞在连接会话ConnSession 关闭队列；判断该ConnSession是否已经标示即将关闭，且最后一次操作的时间需在3、4秒之气；

 如满足这些条件，将队列中的连接会话ConnSession ；否则将该ConnSession 入到队列末尾；