"维持1亿用户在线需要10万台服务器",这里应该是1万台吧？

引用：lordran 发表于 2021-11-02 14:07
"维持1亿用户在线需要10万台服务器",这里应该是1万台吧？

读的很仔细，已勘误，感谢！

还不错

学习了

IO多路复用那里还是看不明白，我是不是应该先把《unix网络编程》读完呢？

引用：一剑开天 发表于 2022-09-07 12:54
IO多路复用那里还是看不明白，我是不是应该先把《unix网络编程》读完呢？

把这篇读一下试试《从根上理解高性能、高并发(三)：深入操作系统，彻底理解I/O多路复用》

引用：JackJiang 发表于 2022-09-07 14:28
把这篇读一下试试《从根上理解高性能、高并发(三)：深入操作系统，彻底理解I/O多路复用》

终于明白了IO多路复用要解决哪个场景下的问题、问题是什么、解决问题的几种方法、以及各个方法实现的大致思路。感谢站长！  以下是我读完后对IO多路复用的理解。

linux 下，一个网络连接对应一个 socket，一个 socket 对应一个文件描述。服务端程序要做的就是将每个文件描述内的数据读到 buffer 中，然后把 buffer 数据处理完成后响应给客户端。如果有一万个并发连接，就意味着服务端应用程序会创建一万个文件描述，然而并非每个文件描述中都是有数据的，没有数据就意味着该文件描述不可读，进程处理该文件描述时就会阻塞。

如果每个文件描述中数据的读取都直接交给进程，那么进程就需要对这些文件描述逐个判断，看它是否可读，若不可读，则进程阻塞在此，这样处理的效率会非常低下，这就是同步阻塞—— BIO 的实现。

后来出现了一种同步非阻塞——NIO，select 的实现是先将这些文件描述（数量上限 1024 个）复制到内核并对它们的状态进行监控，一旦有文件描述的状态变为可读写，则 select 函数返回并唤醒进程。进程被唤醒后遍历所有的文件描述，不可读写则跳过，可读写则执行读写。这种实现 在连接数非常多时，效果并不乐观。

NIO——poll 的实现仅仅消除了 1024 这个文件描述符的数量上限。

NIO——epoll 在监控的同时，将那些可读写的文件描述记录了下来，随后唤醒进程，并将记录好的文件描述提供给进程，这样进程就无需全部遍历一次，可以直接对记录中的文件描述执行读写，效率较高，使用最为广泛。

当所有文件描述都不可读写时，无论使用 sellect、poll 还是 epoll，进程依然处于阻塞状态，所以它们都属于同步 IO。

引用：一剑开天 发表于 2022-09-07 17:24
终于明白了IO多路复用要解决哪个场景下的问题、问题是什么、解决问题的几种方法、以及各个方法实现的大致 ...

捉虫：
原文：“实现方式4：epoll既然逐个排查所有文件句柄状态效率不高，很自然的，如果调用返回的时候只给应用提供发生了状态变化（很可能是数据 ready）的文件句柄，进行排查的效率不就高多了么”
实际应该是：“实现方式4：poll”吧，这是在总结前面 poll 的缺点

引用：肥猫布里奇高 发表于 2023-04-08 15:42
捉虫：
原文：“实现方式4：epoll既然逐个排查所有文件句柄状态效率不高，很自然的，如果调用返回的时候只 ...

已修订，感谢课代表