1 背景
社区版的MySQL的连接处理方法默认是为每个连接创建一个工作线程的one-thread-per-connection（Per_thread）模式。这种模式下，由于系统的资源是有限的，随着连接数的增加，资源的竞争也增加，连接的响应时间也随之增加，如response time图所示。对于数据库整体吞吐而言，则是在资源未耗尽时随着连接数增加，一旦连接数超过了某个耗尽系统资源的临界点，数据库整体吞吐就会各连接的资源争抢而下降，如下图所示。
如何避免在连接数暴增时，因资源竞争而导致系统吞吐下降的问题呢？MariaDB&&Percona中给出了简洁的答案：线程池。线程池的原理在博客中有生动的介绍，其大致可类比为早高峰期间大量汽车想通过一座大桥，如果采用one-thread-per-connection的方式则放任汽车自由行驶，由于桥面宽度有限，最终将导致所有汽车寸步难行。线程池的解决方案是限制同时行驶的汽车数，让桥面时刻保持最大吞吐，尽快让所有汽车抵达对岸。回归到数据库本身，线程池的思路即为限制同时运行的线程数，减少线程池间上下文切换和热锁争用，从而对OLTP工作负载（CPU消耗较少的查询）产生积极影响。当连接数上升时，在线程池的帮助下数据库整体吞吐维持在一个较高水准，如右上图所示。
2 Percona线程池实现
线程池的基本原理为：预先创建一定数量的工作线程（worker线程）。在线程池监听线程（listener线程）从现有连接中监听到新请求时，从工作线程中分配一个线程来提供服务。工作线程在服务结束之后不销毁线程，而是保留在线程池中继续等待下一个请求来临。下面我们将从线程池架构、新连接的创建与分配、listener线程、worker线程、timer线程等几个方面来介绍percona线程池的实现。
2.1 线程池的架构
线程池由有多个线程组（thread group）组成和timer线程组成，如下图所示。线程组的数量是线程池并发的上限，通常而言线程组的数量需要配置成数据库实例的CPU数量，从而充分利用CPU。线程池中还有一个服务于所有线程组的timer线程，负责周期性检查线程组是否处于阻塞状态。当检测到阻塞的线程组时，timer线程会通过唤醒或创建新的工作线程来让线程组恢复工作。
线程组内部由多个worker线程、0或1个listener线程、高低优先级事件队列（由网络事件event构成）、mutex、epollfd、统计信息等组成。如下图所示：
2.2 新连接的创建与分配
新连接接入时，线程池按照新连接的线程id取模线程组个数来确定新连接归属的线程组（thd→thread_id() % group_count）。这样的分配逻辑非常简洁，但由于没有充分考虑连接的负载情况，繁忙的连接可能会恰巧被分配到相同的线程组，从而导致负载不均衡的现象，这是percona线程池值得被优化的点。
选定新连接归属的线程组后，新连接申请被被作为事件放入低优先级队列中，等待线程组中worker线程将高优先级事件队列处理完后，就会处理低优先级的队列中的请求。
2.3 listener线程
listener线程是负责监听连接请求的线程，每个线程组都有一个listener线程。percona线程池的listener采用epoll实现。当epoll监听到请求事件时，listener会根据请求事件的类型来决定将其放入哪个优先级事件队列。将事件放入高优先级队列的条件如下，只需要满足其一即可：
- 当前线程池的工作模式为高优先级模式，在此模式下只启用高优先级队列。（mode == TP_HIGH_PRIO_MODE_STATEMENTS）
- 当前线程池的工作模式为高优先级事务模式，在此模式下每个连接的event最多被放入高优先级队列threadpool_high_prio_tickets次。超过threadpool_high_prio_tickets次后，该连接的的请求事件只能被放入低优先级。（mode == TP_HIGH_PRIO_MODE_TRANSACTIONS）
- 该连接持有表锁
- 连接持有mdl锁
- 连接持有全局读锁
- 接持有backup锁
被放入高优先级事件队列的事件可以优先被worker线程处理。只有当高优先级队列为空，并且当前线程组不繁忙的时候才处理低优先级队列中的事件。线程组繁忙（too_many_busy_threads）的判断条件是当前组内活跃工作线程数+组内处于等待状态的线程数大于线程组工作线程额定值（thread_pool_oversubscribe+1）。这样的设计可能带来的问题是在高优先级队列不为空或者线程组繁忙时低优先级队列中的事件迟迟得不到响应，这同样也是percona线程池值得被优化的一个点。listener线程将事件放入高低优先级队列后，如果线程组的活跃worker数量为0，则唤醒或创建新的worker线程来处理事件。
percona的线程池中listener线程和worker线程是可以互相切换的，详细的切换逻辑会在worker线程模块介绍。epoll监听到请求事件时，如果高低优先级事件队列都为空，意味着此时线程组非常空闲，大概率不存在活跃的worker线程。listener在此情况下会将除第一个事件外的所有事件按前述规则放入高低优先级事件队列，然后退出监听任务，亲自处理第一个事件。这样设计的好处在于当线程组非常空闲时，可以避免listener线程将事件放入队列，唤醒或创建worker线程来处理事件的开销，提高工作效率。
2.4 worker线程
worker线程是线程池中真正干活的线程，正常情况下，每个线程组都会有一个活跃的worker线程。worker在理想状态下，可以高效运转并且快速处理完高低优先级队列中的事件。但是在实际场景中，worker经常会遭遇IO、锁等等待情况而难以高效完成任务，此时任凭worker线程等待将使得在队列中的事件迟迟得不到处理、甚至可能出现长时间没有listener线程监听新请求的情况。为此，每当worker遭遇IO、锁等等待情况，如果此时线程组中没有listener线程或者高低优先级事件队列非空，并且没有过多活跃worker，则会尝试唤醒或者创建一个worker。为了避免短时间内创建大量worker，带来系统吞吐波动，线程池创建worker线程时有一个控制单位时间创建worker线程上限的逻辑，线程组内连接数越多则创建下一个线程需要等待的时间越长。
当线程组活跃worker线程数量大于等于too_many_active_threads+1时，认为线程组的活跃worker数量过多。此时需要对worker数量进行适当收敛，首先判断当前线程组是否有listener线程，如果没有则将当前worker线程转化为listener线程。如果当前有listener线程，则在进入休眠前尝试通过epoll_wait获取一个尚未进入队列的事件，成功获取到后立刻处理该事件，否则进入休眠等待被唤醒，等待threadpool_idle_timeout时间后仍未被唤醒则销毁该worker线程。
worker线程与listener线程的切换如下图所示：
2.5 timer线程
timer线程每隔threadpool_stall_limit时间进行一次所有线程组的扫描（check_stall）。当线程组高低优先级队列中存在事件，并且自上次检查至今没有新的事件被worker消费则认为线程组处于停滞状态。停滞的主要原因可能是长时间执行的非阻塞请求， 也可能发生于线程正在等待但 wait_begin/wait_end （尝试唤醒或创建新的worker线程）被上层函数忘记调用的场景。timer线程会通过唤醒或创建新的worker线程来让停滞的线程组恢复工作。timer线程为了尽量减少对正常工作的线程组的影响，在check_stall时采用的是try_lock的方式，如果加不上锁则认为线程组运转良好，不再去打扰。
timer线程除上述工作外，还负责终止空闲时间超过 wait_timeout 秒的客户端。
