nginx惊群问题如何解决

本篇内容主要讲解“nginx惊群问题如何解决”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“nginx惊群问题如何解决”吧!1. 解决方式
每个worker进程被创建的时候，都会调用ngx_worker_process_init()方法初始化当前worker进程，这个过程中有一个非常重要的步骤，即每个worker进程都会调用epoll_create()方法为自己创建一个独有的epoll句柄。对于每一个需要监听的端口，都有一个文件描述符与之对应，而worker进程只有将该文件描述符通过epoll_ctl()方法添加到当前进程的epoll句柄中，并且监听accept事件，此时才会被客户端的连接建立事件触发，从而处理该事件。从这里也可以看出，worker进程如果没有将所需要监听的端口对应的文件描述符添加到该进程的epoll句柄中，那么其是无法被触发对应的事件的。基于这个原理，nginx就使用了一个共享锁来控制当前进程是否有权限将需要监听的端口添加到当前进程的epoll句柄中，也就是说，只有获取锁的进程才会监听目标端口。通过这种方式，就保证了每次事件发生时，只有一个worker进程会被触发。如下图所示为worker进程工作循环的一个示意图：这里关于图中的流程，需要说明的一点是，每个worker进程在进入循环之后就会尝试获取共享锁，如果没有获取到，就会将所监听的端口的文件描述符从当前进程的epoll句柄中移除（即使并不存在也会移除），这么做的主要目的是防止丢失客户端连接事件，即使这可能造成少量的惊群问题，但是并不严重。试想一下，如果按照理论，在当前进程释放锁的时候就将监听的端口的文件描述符从epoll句柄中移除，那么在下一个worker进程获取锁之前，这段时间各个端口对应的文件描述符是没有任何epoll句柄进行监听的，此时就会造成事件的丢失。如果反过来，按照图中的在获取锁失败的时候才移除监听的文件描述符，由于获取锁失败 香港云主机，则说明当前一定有一个进程已经监听了这些文件描述符，因而此时移除是安全的。但是这样会造成的一个问题是，按照上图，当前进程在一个循环执行完毕的时候，会释放锁，然后处理其他的事件，注意这个过程中其是没有释放所监听的文件描述符的。此时，如果另一个进程获取到了锁，并且监听了文件描述符，那么这个时候就有两个进程监听了文件描述符，因而此时如果客户端发生连接建立事件，那么就会触发两个worker进程。这个问题是可以容忍的，主要原因有两点：这个时候发生的惊群现象只触发了更少的worker进程，比起每次都惊起所有的worker进程要好很多；会发生这种惊群问题的主要原因是，当前进程释放了锁，但是没有释放所监听的文件描述符，但是worker进程在释放锁之后主要是处理客户端连接的读写事件和检查标志位，这个过程是非常短的，在处理完之后，其就会尝试获取锁，这个时候就会释放所监听的文件描述符了，而相较而言，获取锁的worker进程在等待处理客户端的连接建立事件的事件就更长了，因而会发生惊群问题的概率还是比较小的。2. 源码讲解
worker进程初始事件的方法主要是在ngx_process_events_and_timers()方法中进行的，下面我们就来看看该方法是如何处理整个流程的，如下是该方法的源码：上面的代码中，我们省略了大部分的检查工作，只留下了骨架代码。首先，worker进程会调用ngx_trylock_accept_mutex()方法获取锁，这其中如果获取到了锁就会监听各个端口对应的文件描述符。然后会调用ngx_process_events()方法处理epoll句柄中监听到的事件。接着会释放共享锁，最后就是处理已建立连接的客户端的读写事件。下面我们来看一下ngx_trylock_accept_mutex()方法是如何获取共享锁的:上面的代码中，本质上主要做了三件事：通过ngx_shmtx_trylock()方法尝试使用cas方法获取共享锁；获取锁之后则调用ngx_enable_accept_events()方法监听目标端口对应的文件描述符；如果没有获取到锁，则调用ngx_disable_accept_events()方法释放所监听的文件描述符。到此，相信大家对“nginx惊群问题如何解决”有了更深的了解，不妨来实际操作一番吧！这里是开发云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！

相关推荐: 怎么打开电脑中的nrg格式文件

小编给大家分享一下怎么打开电脑中的nrg格式文件，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！1.大家可以直接下载Daemon Tools虚拟光驱软件，随后直接点击启 香港云主机动程…