MyCAT线程模型分析

MyCAT线程模型

 

Mycat线程介绍

 

Timer

Timer单线程仅仅负责调度，任务的具体动作交给timerExecutor。

TimerExecutor线程池，

默认大小N=2

任务通过timer单线程和timerExecutor线程池共同完成。这个1+N的设计方式比较巧妙！

但是timerExecutor跟aioExecutor大小默认一样，不太合理，定时任务没有那么大的运算量。

NIOConnect主动连接事件分离器

一个线程，负责作为客户端连接MySQL的主动连接事件

Server被动连接事件分离器

一个线程，负责作为服务端接收来自业务系统的连接事件

Manager被动连接事件分离器

一个线程，负责作为服务端接收来自管理系统的连接事件

NIOReactor读写事件分离器

默认个数N=processor size，通道建立连接后处理NIO读写事件。

由于写是采用通道空闲时其它线程直接写，只有写繁忙时才会注册写事件，再由NIOReactor分发。所以NIOReactor主要处理读操作

BusinessExecutor线程池

默认大小N=processor size，任务队列采用的LinkedTransferQueue

所有的NIOReactor把读出的数据交给BusinessExecutor做下一步的业务操作

全局只有一个BusinessExecutor线程池，所有链接通道随机分成多个组，然后每组的多个通道共享一个Reactor，所有的Reactor读取且解码后的数据下一步处理操作，又共享一个BusinessExecutor线程池

 

一个SQL请求的线程切换

 

Cobar线程介绍

Timer

Timer单线程仅仅负责调度，任务的具体动作交给timerExecutor。

TimerExecutor线程池，

默认大小N=2

任务通过timer单线程和timerExecutor线程池共同完成。这个1+N的设计方式比较巧妙！

但是timerExecutor跟aioExecutor大小默认一样，不太合理，定时任务没有那么大的运算量。

Server被动连接事件分离器

一个线程，负责作为服务端接收来自业务系统的连接事件

Manager被动连接事件分离器

一个线程，负责作为服务端接收来自管理系统的连接事件

R读写事件分离器

客户端与Server连接后，由R线程负责读写事件（写事件大部分有W线程负责，只有在网络繁忙时才会由小部分写事件是由R线程完成的）。

Handler和Executor线程池

R线程接收到读事件后解码出一个完整的MySQL协议包，下一步由Handler线程池进行SQL解析、路由计算。然后执行任务从Handler线程池转移到Executor线程池，以阻塞方式发送给后端MySQL Server。Executor收到MySQL Server应答后，会由最后一个Executor线程进行聚合，然后交给W线程

W线程

W线程不停遍历LinkedBlockingQueue检查是否有写任务，若有则写入Socket Channel。当Channel繁忙时，W线程会注册OP_WRITE事件，通过R线程进行候补写操作。

ManageExecutor线程池

Cobar对来自Manager的请求和来自Server的请求做了分离，来自管理系统的请求，专门由ManageExecutor线程池处理。

InitExecutor线程池

用来进行后端链路初始化。

 

Cobar为什么那么多个线程池？

可以发现Cobar有下面这么多个线程池

- TimerExecutor线程池(一个)

- InitExecutor线程池(一个)

- ManageExecutor线程池(一个)

- Handler线程池(N个)

- Executor线程池(N个)

 

注意上面的个数单位是线程池，不是线程！所以看起来有些眼花缭乱吧？

我不是Cobar的原作者，只能猜测最什么设计这么多线程池？那就是因为后端采用了BIO！

• 因为后端BIO，所以每一个请求到后端查询，都要阻塞一个线程，前端NIO(Reactor-R线程)必须要把执行任务交给Executor线程池。

• 由于存在聚合要求，前端NIO的一个SQL请求可能会对应多个后端请求，所以不只要阻塞一个Executor线程。为此增加了Handler做中间SQL解析、路由计算，路由计算完毕后再交给Executor执行

• 由于后端是阻塞方式，在时，会导致Executor无空闲线程，为了避免管理端口输入名命令无任何响应的现象，为此增加一个ManageExecutor线程池，专门处理ManageExecutor线程

• 在后端BIO时，除了读写是阻塞方式外，链路建立过程也是阻塞方式，若同时链路建立请求多，也会阻塞大量线程。为避免业务、管理的相互干扰，为此增加了一个InitExecutor线程池专门做后端链路建立

• 所以如果后端BIO改为NIO，并优化逻辑执行过程，避免线程sleep或长时间阻塞，尽量通过Reactor直接计算，就可以大大降低线程上下文切换的损耗，上述各眼花缭乱的线程池就可以合并为一个业务线程池。

一个SQL请求的线程切换

下面是一个SQL请求执行过程的线程切换，可以看到Cobar的线程上下文切换还是比较多的

 

MyCAT与Cobar的比较

 

MyCAT比Cobar减少了线程切换

Cobar的后端采用BIO通信，后端读与后端写因为线程阻塞了，不存在线程切换，没有可比性，所以我们只比较NIO和业务逻辑部分。

Cobar的线程模型中存在着大量的上下文切换,MyCAT的线程调度尽量减少了线程间的切换，以写为例

Cobar是业务线程先把写请求交给专门的W线程，W线程再写过程中发现通道繁忙时再交给R线程；MyCAT对写的做法是业务线程发现通道空闲直接写，只有在通道繁忙时再交给Reactor线程。

减少线程切换与业务可能停顿的矛盾

MyCAT几乎已经达到了线程简化的最高境界，有一个看似可行的方法：可以配置多个NIOReactor，尽可能所有读、解码、业务处理都在Reactor线程中完成，而不必把任务交给BusinessExecutor线程池，从而减少线程的上下文切换，提高处理效率。

但是，不管配置几个Reactor，还是要求多个通道共享一个Reactor，（为什么？因为Reactor最多十几个、几十个，并发的链接通道可能上万个！）如果Reactor在读和解码请求后顺序处理业务逻辑，那么在处理业务逻辑过程中，Reactor就无法响应其它通道的事件了，这个时候如果正好有共享同一个Reactor的其它通道的请求过来，就会出现停顿的现象。

那么如何做呢，就需要具体问题具体分析，要对业务逻辑进行归类：

- 对于业务较重的，比如大结果集排序，则送到BusinessExecutor线程池进行下一步处理；

- 于业务较轻的，比如单库直接转发的情况，则由Reactor直接完成，不再送线程池，减少上下文切换。

特别说明ER分片机制

如果涉到ER分片，MyCAT目前的机制：计算路由时以阻塞同步方式调用FetchStoreNodeOfChildTableHandler，若由Reactor直接进行路由计算，会导致其它通道停顿现象。把ER分片同步改异步是个看似可行的方法，但这个改造工作量较大，会造成原来完整路由计算逻辑的碎片化。

即使ER分片同步改异步了，每次子表操作都要遍历父表对性能损耗较大，即使采用缓存也不能最终解决问题。个人觉得，ER分片这个功能比较鸡肋，建议生产部署时绕开这个功能，直接通过关联字段分片或表设计时增加冗余字段。

数据验证

1.测试sql从收到请求到下推的总时长，如果时间可容忍，则不必切换到线程池。忽略ER分片。

2.对于manager端口的命令，若存在执行时间比较的，也需要改为线程池来执行

3.对于收到的应答，大部分都不必切换到线程池。

4.对于大量数据排序，只有在排序时，构造执行任务，切换到线程池完成。

更多内容请关注微信公众号：it_haha

转载于:https://my.oschina.net/u/2836632/blog/704074