大咖助场1 | 李玥：高并发场景下如何优化微服务的性能?

先回答一下思考题： 首先是poll和 select 函数对比， poll 函数和 select 不一样的地方就是，在 select 里面，文件描述符的个数已经随着 fd_set 的实现而固定，没有办法对此进行配置；而在 poll 函数里，我们可以控制 pollfd 结构的数组大小，这意味着我们可以突破原来 select 函数最大描述符的限制，在这种情况下，应用程序调用者需要分配 pollfd 数组并通知 poll 函数该数组的大小。 epoll 与poll相对比，epoll不同于 poll 的是，epoll 不仅提供了默认的 level-triggered（条件触发）机制，还提供了性能更为强劲的 edge-triggered（边缘触发）机制。条件触发的意思是只要满足事件的条件，比如有数据需要读，就一直不断地把这个事件传递给用户；而边缘触发的意思是只有第一次满足条件的时候才触发，之后就不会再传递同样的事件了。一般我们认为，边缘触发的效率比条件触发的效率要高，这一点也是 epoll 的杀手锏之一。 答案来源主要是极客专栏盛延敏老师的《网络编程实战》。 非常的喜欢李玥老师，老师的两门课都收获很多。比如《消息队列高手课》里面实现一个简单的RPC框架，真的是意外之喜，买一送一。还有《后端存储实战课》，意外之喜就是结束语了，感觉又是买一送一了，让我学到了很多技术之外的东西，感谢李玥老师。（也许秋招我可以投京东试一试😄）

线程数量需要根据业务特征io密集，计算密集型 计算密集型线程数量 CPU核数+1 IO密集型 线程数量=(CPU空闲时间+CPU工作时间)/CPU工作时间 + 1

感觉说得太绝对了，现网DB链接池配置32不现实，业务侧mysql访问组件一个进程就会建立几个链接，多起几个进程mysql就受不了了

select、poll、epoll 不是aio 模型。

对于独立应用socket 的网关服务和处理服务的线程数实际上是很低的，多数只能达到应用瓶颈而不会出现服务器CPU或IO瓶颈。Linux内核的select方式在处理socket似乎优于后面两个，曾经在一个项目中遇到了这个问题，选择select 在超过线程数的并发下服务器不会出现拒绝连接的响应。

如果是应用服务器有20多台，数据库是一台master3台salve的话，这样的数据库连接池怎么设置呢？希望老师能回答

老师你好，我有两个问题想请教一下。 1 多工位解决等待问题，这部分应该解决的是io读写的时间吧？ 2 异步io，在发送信号之前是在做下一个请求么？如果是在处理下个请求，那么信号唤醒，这里会涉及线程的切换么？