mysql threadpool_MySQL学习分享--Thread pool

基于《MySQL学习分享--Thread pool》对Thread pool架构设计的详细了解，本文主要对Thread pool的实现进行分析，并根据Mariadb和Percona提供的开源实现，进行简单的比较和评估。

1、《The Thread Pool Plugin》

MySQL官方文档中，对Thread pool进行了详细的介绍，主要从实现和使用角度进行了说明。MySQL企业版实现通过插件方式实现，对源码逻辑没有侵入，是比较友好的方式。文档描述的实现机制方面，跟架构设计基本无出入。

其中，thread_pool_size控制线程组的大小，thread_pool_stall_limit标志sql执行异常的情况，thread_pool_prio_kickup_timer控制用户线程的优先级转化。

根据文档提供的信息，以及架构设计的思想，抽象出以下几种处理逻辑：

1.1 No executing and empty queue

在当前线程组内，既没有当前执行的sql语句，也没有等待的用户线程在队列中时，线程组内的监听线程立即执行当前用户请求的sql。具体逻辑如下图所示：

图1.1 No executing and empty queue

图中是一个线程组内流程，每个线程组内有两个优先级队列(high/low priority queue)，当前没有执行sql并且队列为空时，新的用户连接的请求，监听线程会立即执行sql到DB。

1.2 Low priority queue

当前线程组内的高优先级队列为空，低优先级的队列不为空时，监听线程会从低优先级队列中取用户请求，执行sql到DB。具体处理逻辑如下图所示：

图1.2 Low priority queue

特别的，如果一个事务有多条sql，当从低优先级队列中取第一条sql开始执行时，该事务的其他sql语句，全部进入高优先级队列。

1.3 High priority queue

在当前线程组内，如果高优先级队列中有用户请求，监听线程会优先从高优先级队列中取用户请求，优先执行sql到DB。高优先级队列执行完了，再从低优先级队列中取用户请求。

图1.3 High priority queue

此外，参数thread_pool_high_priority_connection会将当前session中的所有sql迁移到高优先级队列中。

1.4 Priority kickup timer

在低优先级队列中的用户请求超过thread_pool_prio_kickup_timer时间时，会从低优先级队列中迁移到高优先队列中。具体的处理逻辑如下图所示：

图1.4 Priority kickup timer

1.5 Stall limit

当监听线程由于大事务阻塞，超过thread_pool_stall_limit参数限制时，监听线程继续执行，同时启动新的监听线程，从队列中继续往下执行。具体逻辑如下所示：

图1.5 Stall limit

通过以上分析可知，thread_pool_stall_limit和thread_pool_prio_kickup_timer参数是主要的性能优化参数。如果thread_pool_stall_limit设置与业务场景不匹配时，会导致单个线程组内有大量的执行线程，这样就会导致持续创建监听线程，并且大量的线程切换。而thread_pool_prio_kickup_timer参数设置不合理，将会导致频繁的从低优先级队列迁移到高优先级队列，消耗大量的系统资源。因此在性能优化时，需要根据业务模型和场景进行测试和设置。

2、《Thread pool in MariaDB 5.5》

MariaDB 5.5引入了Thread pool，设计思想与MySQL企业版设计几乎一致。MariaDB嵌入到Server层，而没有使用插件的方式，这是实现上的一个重大差别。MariaDB通过thread_handling设置线程类型实现线程池和one-to-one方式方式的转化。从实现角度来看，通过配置文件设置该参数，不能动态调整。

两者设计上都采用了线程组，但是MariaDB将实现进行了进一步的细化，增加了thread_pool_max_threads参数控制线程池的最大线程数。此外，针对不同的系统，采用不同的IO复用方式，提高性能。

两者都通过thread_pool_stall_limit参数避免大事务阻塞的问题。但是没有分Low/High priority queue，也没有thread_pool_prio_kickup_timer参数影响队列之间的转化。MariaDB通过thread_pool_stall_limit来避免大事务的阻塞，并且不限制线程的并发，因此也不需要优先级队列的方式，防止事务持续不被执行的饥饿问题。从这一点上来看，MySQL的设计更加合理一点，在大量大事务阻塞的时候，并发数较多，因抢占资源性能降低，而小事务由于阻塞会长时间得不到响应。

MariaDB引入extra-port和extra-max-connections参数，用于防止在没有连接资源时，super用户可以登陆进行管理操作。

3、《Thread pool》

Percona的Thread pool是基于MariaDB的实现，并参考了MySQL的设计思想，进行了优化和改进。

Percona参考MySQL的优先级队列思想，将队列分为高优先级队列和普通队列。引入thread_pool_high_prio_tickets参数，当满足一定条件时，用户请求会从普通队列中移到高优先级队列中。正是MariaDB中分析的，目标是降低用户连接的并发数。

结论

通过以上内容分析可知，Thread pool的实现来看，设计思想基本上一致。从实现来看，MySQL企业版实现采用Plugin的方式，可以动态操作，不影响正常逻辑。而MariaDB和Percona采用buildin的方式，通过配置文件，不够灵活。从实现细节来看，MariaDB除了优先级队列之外，与MySQL企业版基本实现思想一致，但是在很多方面都进行了优化和精细。Percona基于MariaDB的实现，参考MySQL企业版的优先级队列，进行了优化和改进。

总体来看，Percona的Thread pool作为开源的实现，与MySQL企业版的设计思想中提到的几个问题，也都很好的解决，应该是使用和了解Thread pool实现的最佳选择。

参考