最近设计了一个网络服务器程序，对于4C8G的机器配置，TPS可以达到5W。业务处理逻辑是简单的字符串处理。服务器接收请求后对下游进行类似广播的发送。在此分享一下设计方式，如果有改进思路欢迎大家交流分享。

程序运行在CentOS7.9操作系统上，GCC使用4.8.5版本，网络是千兆网。

接收流程

展示如下：

 

epollin进来之后会进行会话组的读锁锁定，这样会话不可能在上锁期间析构掉，保证了会话指针（包括其内部的接收缓存）的安全。在会话处理内部对消息缓冲区进行了尝试上锁。如果上锁失败则返回（这样保证了如果一个会话的数据特别多，其他网络接收线程也可以及时处理其他会话进来的数据）。

 发送流程

如下：

发送线程有两种模式：直接发送、缓冲发送。直接发送模式就是直接将需要发送的数据发送处理，缓冲发送是将数据写到会话的缓冲区，然后进行发送。直接发送的好处就是可以不用复制数据，这样可以减少CPU和内存的占用，但是坏处就是由于没有对于每个会话进行单独的缓冲，因此需要遍历每个会话，对数据进行依次发送。此时，如果有一个会话的接收速度特别慢，就会导致整体的发送效率降低。缓冲发送模式则不存在这个问题，一个会话的接收速度慢，但是它有自己的缓冲区，所以可以直接把数据复制到它的缓冲区中，然后继续下一个会话的发送。

系统使用优先直接发送，如果遇到EAGAIN时候直接转到缓冲区发送的方式。这样就可以保证尽量不复制缓冲区，同时在发送遇到阻塞时候也能不影响其他会话。

 效果测试

在5W的TPS下可以接收8个下游系统，上下游网络流量已经几乎达到带宽极值，CPU占用率67%，内存在运行48小时后会达到78M。

但是还是存在问题。1）单独使用缓存发送模式的时候有一个问题，就是CPU占用率特别高，每多一个会话则CPU的占用率升值需要升高10%-20%（这里似乎没有CAS导致的CPU占用，同时，使用的锁也全都是普通锁，并没有自旋锁）；2）下游接收速度很慢的时候CPU占用率会提高到70%以上。