问题的背景：在建立连接的时候，Nginx处于充分发挥多核CPU架构性能的考虑，使用了多个worker子进程监听相同端口的设计，这样多个子进程在accept建立新连接时会有争抢，这会带来著名的“惊群”问题，子进程数量越多越明显，这会造成系统性能的下降。如何解决惊群问题-post事件处理机制很多操作系统的最新版本的内核已经在事件驱动机制中解决了惊群问题，但Nginx作为可移植性极高的web服务器，还是在自身的应用层面上较好的解决了这一问题。Nginx规定了同一时刻只有唯一一个worker子进程监听web端口，这一就不会发生惊群了，此时新连接事件只能唤醒唯一的正在监听端口的worker子进程。如何限制在某一时刻是有一个子进程监听web端口呢？在打开accept_mutex锁的情况下，只有调用ngx_trylock_accept_mutex方法后，当前的worker进程才会去试着监听web端口。我的问题：假定当前所有的woker进程处于休眠状态，当连接事件发生的时候 ，是不是所有的wokrer进程都会 尝试获取锁，如果获取成功就会 处理连接事件。 那么这种情况下 不也 回导致 连接事件发生时，唤醒所有的wokrer进程 去竞争获取锁吗？惊群 问题 就是解决 如下问题的而 使用锁的解决方案中 如何避免多个worker进程 被唤醒竞争锁？？
添加回答
举报
0/150
提交
取消