epoll编程，如何实现高并发服务器开发？

～～～ 2017-09-24增加～～～

评论区域中有很多干货. 有兴趣的学生可以看看. 由于我很懒，因此我将不再编辑和更新原始答案.

看着它，最后一次编辑是7月15日，我没想到这么久，而且有些人担心这个问题: ）

以下是原始答案.

～～～ 2018-03-15增加～～～

评论区域中的f框架今天已开源. 如果您有兴趣，请继续: highras / fpnn

相关的SDK也于几天前开源. 另请参阅: HighRAS

注意: 目前，只有框架和SDK是开源的epoll源码，而FPNN技术生态系统的其他部分尚未开源. 框架文档有点滞后，大多数SDK文档暂时不可用.

～～～ 15年以来的原始答案～～～

免费答案.

根据重要性和基本水平，让我们破坏顺序~~

首先返回问题，然后说出解决方法.

注意: 以下数据基于Amazon AWS c3.xlarge模型.

虚拟CPU: 4

内存: 7.5 GB

c3.xlarge的配置和价格: AWS |亚马逊EC2

～～～～～～～～～～分界线～～～～～～～～～

2. 在检查了很多信息之后，单凭多进程是不现实的，但是多线程开发Linux系统对线程数有上限，如何解决？

多线程限制？有！但这重要吗？考虑驱动无限线程，每个线程都在运行吗？

线程调度有系统资源开销！ ！ ！ ！

线程调度有系统资源开销！ ！ ！ ！

线程调度有系统资源开销！ ！ ！ ！

谈论重要的事情三遍~~！ ！ ！

从理论上讲，如果没有I / O等待等使CPU空闲的事物，则线程数最好等于CPU内核数.

线程数最好等于CPU内核数！ ！ ！

线程数最好等于CPU内核数！ ！ ！

线程数最好等于CPU内核数！ ！ ！

我重复三遍重要的事情.

实际的栗子:

我负责公司网络框架的架构设计和开发. 在4核c3.xlarge虚拟机上，在对框架进行压力测试时，2000个工作线程的QPS（这里被理解为一个小的TPS问题）远低于4个工作线程的QPS！

4个工作线程以及其他辅助线程，每秒QPS最高350,000. 2000个工作线程，加上相同的辅助线程，每秒最大QPS 150,000 ~~！

大部分时间和其他系统资源都花费程切换上！这就是为什么在某些情况下单线程程序要比多线程程序快的原因！ （多线程线程库的单线程仿真，您可以参考状态线程: 足够简单. ）

1. 该系统处理的服务是多客户端访问. 一旦连接基本连接了8个小时以上，但客户端登录后基本上处于非活动状态，则只会生成与客户端触发相关的设置事件的活动通信.

6. TCP协议用于系统开发.

当前的开放框架，TCP长链接，最大压力测试链接为108万，总QPS为60,000.

该服务器也是c3.xlarge. 我打开了18台计算机进行客户端压缩，每台计算机都有60,000个链接（记住要修改/ proc / sys / net / ipv4 / ip_local_port_range，否则一台计算机将没有那么多链接）.

4. 客户端访问时间是随机的，在初始系统运行期间不会有成千上万的用户同时登录，但是一旦用户访问服务器，它就不会长时间断开连接.

按测试，每批添加60,000个链接.

5. epoll技术可以与多线程技术一起使用吗？怎么？

在Linux上，必须！ ！ ！

3. 如何设计和开发用于QQ和SKYPE等多客户端登录软件的服务器？

没有通用的，它实际上是根据特定需要定制的！ ！ ！

没有通用的，它实际上是根据特定需要定制的！ ！ ！

没有通用的，它实际上是根据特定需要定制的！ ！ ！

但是分布式的，分散的，无状态的，一致的哈希……都是必要的~~~！

但是分布式的，分散的，无状态的，一致的哈希……都是必要的~~~！

但是分布式的，分散的，无状态的，一致的哈希……都是必要的~~~！

（说话三遍，筋疲力尽~~~喝点水~~）

您可能希望搜索以发展网络架构和服务器架构. 中小型公司基本上可以按照这些例程进行操作. 图片太多，太罗word了. 这些都是重复性的工作epoll源码，所以我不会写，请自己搜索.

您问一家大公司？请参考第一句话: 没有一般性，实际上是根据特定需要定制的！ ！ ！

要补充一点: 搜索将非常依赖于memcached，redis等. 但是我在公司中使用过它，这一点非常重要，但仅适用于PHP. 后端服务集群使用专用的缓存〜！ ！

专用缓存~~！有逻辑~~！自己开发~~！

专用缓存~~！有逻辑~~！自己开发~~！

专用缓存~~！有逻辑~~！自己开发~~！

再聊三遍.

支持1.6亿注册用户.

7. 希望您能给出详细的开发框架.

框架？是参考架构设计吗？

有很多框架，例如ICE，Facebook Thrift，Apache Thrift等. ~~

请注意，最后两个节俭并不完全相同~~！ ！ ！

然后该怎么做:

没有固定的例程！ ！ ！唯一要注意的地方！ ！ ！

没有固定的例程！ ！ ！唯一要注意的地方！ ！ ！

没有固定的例程！ ！ ！唯一要注意的地方！ ！ ！

再三遍.

要点:

最少的线程切换

最小共享冲突

尝试尽可能地无锁

工作线程数应尽可能等于CPU内核数

尽量不要让线程等待时间片

应尽可能简化逻辑，以避免不必要的封装和转发

工程学不是学术上的，OOP应该让位于易于使用，高性能和良好的维护~~！

（这是因为ICE概念太多，太复杂了，最后一家公司开发了自己的框架. 这是因为Facebook Thrift太冗长，一个异步的必须进行多次弯曲，并且链接也绑定到了CPU核心（如果只有Link，100,000 QPS，您会发现一个核心太忙了，另一个核心正在吃干米〜），现在该公司决定开发自己的网络框架. ）

EPOLL: 边沿触发，一次射击！ ！ ！

不要在epoll_wait（）线程中的non-epoll_wait（）中花费太长时间.

如果可以使用原子级，则不要使用互斥锁（这是C ++ 11）

上面没有重复三遍，太罗word了~~~

～～～～～～～～～～～～～～ 7月3日添加～～～～～～～～～～～～～～

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-202648-1.html