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事務被允許繼續進行。提交階段的本地事務失敗並出現認證錯誤。

三、其他線程

1、服務線程

此線程在啟動時創建並用於執行輔助服務。它有兩個主要功能：

??在高速緩存的寫入集被清除到所述級別後，它釋放GCache緩沖區。
??它通知群集組各個節點已提交到此級別的事務。每個節點都維護有關集群中其他節點的一些基本狀態信息。收到該消息後，信息將在此本地元數據中更新。

2、接收線程

該gcs_recv_thread線程是第一個查看組中收到的所有消息的線程。

它會嘗試根據收到的每條消息分配操作。它將這些消息添加到中央FIFO隊列中，然後由Applier線程處理。消息可以包含不同的操作，如狀態更改，配置更新，流量控制等。

一個重要的操作是處理一個寫集，它實際上是將事務應用於數據庫對象。

3、Gcomm連接線程

gcomm連接線程GCommConn::run_fn 用於協調低層組通信活動。把它想象成一個用於溝通的黑匣子。

4、基於動作的線程

除上述之外，還有一些線程是按需創建。SST為捐助者和joiner創建線程（最終派生出一個子進程來托管所需的SST腳本），IST創建接收者和異步發送者線程，PageStore創建後臺線程以刪除創建的文件。

如果啟用校驗和並且復制的寫入集足夠大，則校驗和將作為單獨線程的一部分完成。

四、參考鏈接

https://www.percona.com/doc/percona-xtradb-cluster/LATEST/manual/threading_model.html

作者：Leshami 來源：CSDN 原文：https://blog.csdn.net/leshami/article/details/79970818?utm_source=copy 版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

mysql之 Percona XtraDB Cluster集群線程模型