1. 事件驱动，这个只是为了IO和CPU异步，让CPU从IO等待中解放出来，这样就能在CPU循环中往死里accept连接了，nginx就靠这个把apache玩死的，nodejs的快不仅仅因为这个，语言层的magic就扯远了。
2. 利用双核，2个核就2个进程，一个进程一个事件驱动核（epoll，select啥的），增加链接吞吐。
3. 参数调优，这才是最重要的一步，一个Socket连接默认是有内存消耗的，我不记得Python的Socket占用是4M还是多少来着了，当然这个也可以调优，eurasia的作者沈大侠说过可以搞到2M来着？当然这对于一个24G的服务器来说300w还是搞不定的，但是就送TCP本身来分析的话，tcp_rmem/tcp_wmem，这2个系统tcp读写缓存默认都很高，拉低到4k，然后把tcp_mem也得改下，这个说起来太麻烦，man一下就有了，总的来说就是得拉高High值
4. 网卡要给力，端口给足，句柄加高。
单服务器300万长连接还是蛮有挑战的。处理方式无非那些，Select，零拷贝等。我想问一下，300万长连接的心跳包多少qps?10秒一个心跳就是30万qps，峰值还不止。维持这么多连接，不管你的程序顶不顶的住，网卡得先顶得住。
netty框架试试，nio模式才可能办到的
单服务器承担3万个链接意义不大，对硬件本身是一种挑战，不管采用什么复用模型，还是分布式吧
首先你想用一个端口去扛300万个连接那简直是做梦。所以，第一步要把端口分散，用300个端口去侦听。然后是关键一步，写内核模块，在Local in链上，把指定端口的报文（比如80）按源地址做负载均衡，分发到这300个端口上。这是三层负载均衡，比nginx的七层负载均衡性能高无数倍。
另外一个办法，绕过Linux协议栈，使用用户层报文处理框架，比如DPDK，再自己写TCP协议栈 ，只要网卡有足队列和有足够的CPU核心数，就能扛得住。比如常见的10G卡有128个队列，配合128个核心，就能发挥网卡的最大效能。DPDK工作在轮询模式，小包处理尤其出色，像SYNC包，KEEPALIVE包。
linux
