探索惊群 ①

2021-09-25

惊群比较抽象,类似于抢红包 😁。它多出现在高性能的多进程/多线程服务中,例如:nginx。

探索惊群 系列文章将深入 Linux (5.0.1) 内核,透过 多进程模型 去剖析惊群现象、惊群原理、惊群的解决方案。

  1. 探索惊群 ①
  2. 探索惊群 ② - accept
  3. 探索惊群 ③ - nginx 惊群现象
  4. 探索惊群 ④ - nginx - accept_mutex
  5. 探索惊群 ⑤ - nginx - NGX_EXCLUSIVE_EVENT
  6. 探索惊群 ⑥ - nginx - reuseport
  7. 探索惊群 ⑦ - 文件描述符透传

1. 概述

1.1. 惊群现象

多进程睡眠等待 共享 资源,当资源到来时,多个进程被 无差别 唤醒,争抢处理资源。


1.2. 惊群影响

惊群导致软件系统工作效率低下:

  1. 部分进程被频繁唤醒却获取资源失败,导致进程上下文频繁切换,系统资源开销大。
  2. 多进程争抢共享资源,有的抢得多,有的抢得少,资源分配不均。

1.3. 惊群原因

进程睡眠 唤醒 时机问题,详细请参考:探索惊群 ③ - nginx 惊群现象


2. 解决方案

需要围绕两个方面去展开。

  1. 避免共享资源争抢(独占)。
  2. 资源尽量合理分配。

换个角度去思考,如果红包私发,而不是扔进群组里… 这个思路应该是解决惊群问题的关键。😎


我们可以参考 nginx 解决惊群问题的经典方案:

  1. 探索惊群 ④ - nginx - accept_mutex
  2. 探索惊群 ⑤ - nginx - NGX_EXCLUSIVE_EVENT
  3. 探索惊群 ⑥ - nginx - reuseport

2.1. reuseport

内核解决惊群问题,目前 nginx 最好的惊群解决方案,基于 linux 内核 so_reuseport 端口重用网络特性。

  1. 每个子进程拥有独立的 listen socket 资源队列,避免资源争抢;多个队列也提升了并发吞吐。
  2. 新链接通过网络四元组通过哈希分配到各个子进程的 listen socket 资源队列,资源分配相对合理(负载均衡)。

2.2. NGX_EXCLUSIVE_EVENT

内核解决惊群问题,基于 linux 4.5+ 内核增加的 epoll 属性 EPOLLEXCLUSIVE 独占资源属性。

原理非常简单,只唤醒一个睡眠等待的进程处理资源。避免无差别地唤醒多个进程,尽量使得各个进程忙碌起来。

缺点:

  1. 多个进程争抢一个 listen socket 的共享资源。
  2. 单个资源队列,将会是并发吞吐瓶颈。

2.3. accept_mutex

应用层解决惊群问题,多个子进程通过应用层抢锁,成功者可以独占 listen socket 获取资源的权利。

优点:有效地避免了惊群。

缺点:

  1. 因为抢锁时机问题,原来抢到锁的进程下次抢到锁的概率很高,导致有些进程很忙,有些没那么忙,负载不均,资源利用率比较低。
  2. 一个时间段内,只有一个子进程独占 listen socket 的共享资源,无法同时利用多核优势。
  3. 单个资源队列,将会是并发吞吐瓶颈。

3. 参考