Percona XtraDB Cluster集群线程模型

Percona XtraDB集群创建一组线程来为其操作提供服务，这些线程与现有的MySQL线程无关。有三个主要线程组：

一、Applier线程

Applier线程应用从其他节点接收的写入集。写消息直接通过gcv_recv_thread。

使用wsrep_slave_threads变量控制线程的数量。默认值是1，这意味着至少有一个wsrep applier线程存在来处理请求。

Applier线程等待一个事件，一旦它捕获到事件，它就使用普通的从应用线程路径应用它，并用wsrep-customization中继日志信息应用路径。这些线程与从属工作线程类似（但不完全相同）。

使用“ Apply and Commit Monitor ” 可以实现协调。一个事务通过两个重要的状态：APPLY和COMMIT。每个事务都向自己申请的监控器进行注册，其申请顺序已经定义。 因此，在应用此事务之前，应用所有具有小于此事务序号的序号（seqno）的事务。 commit也是这样做的（last_left> = trx_.depends_seqno（））。

二、回滚线程

只有一个回滚线程在发生冲突时执行回滚。

??并行执行的事务可能会发生冲突并可能需要回滚。
??Applier事务总是优先于本地事务。这很自然，因为Applier事务已被群集接受，并且一些节点可能已经应用了它们。本地冲突交易仍然有一个回滚窗口。

所有需要回滚的事务都被添加到回滚队列中，并通知回滚线程。回滚线程然后迭代队列并执行回滚操作。

如果事务在节点上处于活动状态，并且节点从群集组接收到与本地活动事务冲突的事务写入集，则此类本地事务始终被视为受影响事务以回滚。

出现冲突时，事务处于提交状态或执行阶段。执行阶段的本地事务被强行kill，以等待Applier事务被允许继续进行。提交阶段的本地事务失败并出现认证错误。

原文链接