万字总结线程池

本文将从背景、原理、架构、实现、参数状态等方面详细介绍percona-线程池。此外，还将简单介绍腾讯云企业级MySQL(CDB)内核技术--TXSQL，关于线程池的动态启停、负载均衡以及快速断连等优化。

「第一部分 背景」

社区版的MySQL的连接处理方法默认是为每个连接创建一个工作线程的one-thread-per-connection（Per_thread）模式。这种模式下，由于系统的资源是有限的，随着连接数的增加，资源的竞争也增加，连接的响应时间也随之增加，如response time图所示。

 

对于数据库整体吞吐而言，则是在资源未耗尽时随着连接数增加，一旦连接数超过了某个耗尽系统资源的临界点，数据库整体吞吐就会随着各连接的资源争抢而下降，如下图所示。

 

如何避免在连接数暴增时，因资源竞争而导致系统吞吐下降的问题呢？MariaDB&&Percona中给出了简洁的答案：线程池。线程池的原理在博客中（链接参考文献1）有生动的介绍，其大致可类比为早高峰期间大量汽车想通过一座大桥，如果采用one-thread-per-connection的方式则放任汽车自由行驶，由于桥面宽度有限，最终将导致所有汽车寸步难行。线程池的解决方案是限制同时行驶的汽车数，让桥面时刻保持最大吞吐，尽快让所有汽车抵达对岸。回归到数据库本身，线程池的思路即为限制同时运行的线程数，减少线程池间上下文切换和热锁争用，从而对OLTP工作负载（CPU消耗较少的查询）产生积极影响。当连接数上升时，在线程池的帮助下数据库整体吞吐维持在一个较高水准，如图所示。

 

 

「第二部分 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）。这样的分配逻辑非常简洁，但由于没有充分考虑连接的负载情况，繁忙的连接可能会恰巧被分配到相同的线程组，从而导致负载不均衡的现象，这是percon