实际项目中,我们有很多高并发的场景需要考虑、设计,在高并发领域有个很有特点的名词叫惊群效应,你了解吗?
![effc58eeb2204f48c80079c88284010f.png](https://i-blog.csdnimg.cn/blog_migrate/815e882b4574f597582a428e1dcda35d.jpeg)
一、啥是惊群效应
啥叫惊群效应,有个例子说明的很透彻。当你往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到食物的鸽子只好回去继续睡觉, 等待下一块食物到来。这样,每扔一块食物,都会惊动所有的鸽子,即为惊群。
![c572dd17551f16261a8510b8261587bc.png](https://i-blog.csdnimg.cn/blog_migrate/0ec5014be989e903a4c88bf48e255783.jpeg)
也就是说,虽然只扔了一块实物,但是惊动了整个鸽群,最后只有一个鸽子抢到食物了,浪费了其他鸽子的能量。
二、惊群导致的问题
对于操作系统来说,多个进程/线程在等待同一资源是,也会产生类似的效果,其结果就是每当资源可用,所有的进程/线程都来竞争资源,造成了资源的浪费。
- 系统对用户进程/线程频繁的做无效的调度、上下文切换,系统系能大打折扣。
- 为了确保只有一个线程得到资源,用户必须对资源操作进行加锁保护,进一步加大了系统开销。
三、常见的惊群场景
1、linux惊群
linux中惊群主要是accept惊群和epoll惊群。
1)accept惊群,以多进程为例,在主进程创建监听描述符listenfd后,fork()多个子进程,多个进程共享listenfd,accept是在每个子进程中,当一个新连接来的时候,会发生惊群。
2)epoll惊群分两种,一是在fork之前创建epollfd,所有进程共用一个epoll;二是在fork之后创建epollfd,每个进程独用一个epoll。
epoll惊群和accept惊群类似,共享一个epollfd, 加锁或标记解决。在新的linux内核版本中都已得到解决。
2、nginx惊群
在nginx中使用的epoll,是在创建进程后创建的epollfd。因些会出现类似linux的惊群问题。即每个子进程worker都会惊醒。
nginx使用了互斥锁来解决惊群的问题。
- 采用了主动的方法去把监听描述符放到epoll中或从epoll移出。
- 采用互斥锁去解决谁来accept问题,保证了同一时刻,只有一个worker接收新连接(所以nginx并没有惊群问题)。
- 根据自已的载负情况,决定去不去抢锁,简单方便地解决负载,防止进程因业务太多而导致所有业务都不及时处理。
3、线程池惊群
多线程设计中,经常会用到互斥和条件变量的问题。当一个线程解锁并通知其他线程的时候,就会出现惊群的现象。
- pthread_mutex_lock,线程互斥锁的加锁及解锁函数。
- pthread_cond_wait,线程池中的消费者线程等待线程条件变量被通知。
- pthread_cond_signal,生产者线程通知线程池中的某个或一些消费者线程池,接收处理任务。
这里的惊群现象出现在3里,pthread_cond_signal,语义上看,是通知一个线程。调用此函数后,系统会唤醒在相同条件变量上等待的一个或多个线程(可参看手册)。如果通知了多个线程,则发生了惊群。
1)一般用法,
- 所有线程共用一个锁,共用一个条件变量。
- 当pthread_cond_signal通知时,就可能会出现惊群
2)解决惊群的方法,
- 所有线程共用一个锁,每个线程都有自己的条件变量。
- pthread_cond_signal通知时,定向通知某个线程的条件变量,不会出现惊群。
![75d90673031a9179c89ef3275434dbbf.png](https://i-blog.csdnimg.cn/blog_migrate/01317125e6d0ba3d0fe38d3060c87333.jpeg)
好了,惊群效应大体了解了吧。惊群有不同的场景和解决方案,在高并发场景下,需要做适当考虑哦。