nginx 是如何分配 worker 进程连接数的

客户端连接过来后,多个空闲的进程,会竞争这个连接,很容易看到,这种竞争会导致不公平,如果某个进程得到 accept 的机会比较多,它的空闲连接很快就用完了,如果不提前做一些控制,当 accept 到一个新的 tcp 连接后,因为无法得到空闲连接,而且无法将此连接转交给其它进程,最终会导致此 tcp 连接得不到处理,就中止掉了。很显然,这是不公平的,有的进程有空余连接,却没有处理机会,有的进程因为没有空余连接,却人为地丢弃连接。那么,如何解决这个问题呢?首先,Nginx 的处理得先打开 accept_mutex 选项,此时,只有获得了 accept_mutex 的进程才会去添加accept事件,也就是说,Nginx会控制进程是否添加 accept 事件。Nginx 使用一个叫 ngx_accept_disabled 的变量来控制是否去竞争 accept_mutex 锁。在第一段代码中,计算 ngx_accept_disabled 的值,这个值是 Nginx 单进程的所有连接总数的八分之一,减去剩下的空闲连接数量,得到的这个 ngx_accept_disabled 有一个规律,当剩余连接数小于总连接数的八分之一时,其值才大于 0,而且剩余的连接数越小,这个值越大。再看第二段代码,当 ngx_accept_disabled 大于 0 时,不会去尝试获取 accept_mutex 锁,并且将 ngx_accept_disabled 减 1,于是,每次执行到此处时,都会去减 1,直到小于 0。不去获取 accept_mutex 锁,就是等于让出获取连接的机会,很显然可以看出,当空余连接越少时,ngx_accept_disable 越大,于是让出的机会就越多,这样其它进程获取锁的机会也就越大。不去 accept,自己的连接就控制下来了,其它进程的连接池就会得到利用,这样,Nginx 就控制了多进程间连接的平衡了。

白话说就是,nginx 会设置一个 单个进程的可连接总数的 八分之一 作为切换连接的标准, 当这个标准 减去 单个进程的剩余连接数 大于0 时,即所剩的连接数已经小于 总连接数的八分之一时,会让该进程让出 连接机会,即在该进程连接数所剩不多时,切换连接进程。

上代码

ngx_accept_disabled = ngx_cycle->connection_n / 8
        - ngx_cycle->free_connection_n;

    if (ngx_accept_disabled > 0) {
        ngx_accept_disabled--;

    } else {
        if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
            return;
        }

        if (ngx_accept_mutex_held) {
            flags |= NGX_POST_EVENTS;

        } else {
            if (timer == NGX_TIMER_INFINITE
                    || timer > ngx_accept_mutex_delay)
            {
                timer = ngx_accept_mutex_delay;
            }
        }
    }
世事洞明皆学问
原文地址:https://www.cnblogs.com/Json159/p/11995863.html