本文将从背景、原理、架构、实现、参数状态等方面详细介绍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)。这样的分配逻辑非常简洁,但由于没有充分考虑连接的负载情况,繁忙的连接可能会恰巧被分配到相