MYSQL線程池總結(一)

     線程池是Mysql5.6的一個核心功能，對於服務器應用而言，不管是web應用服務仍是DB服務，高併發請求始終是一個繞不開的話題。當有大量請求併發訪問時，必定伴隨着資源的不斷建立和釋放，致使資源利用率低，下降了服務質量。線程池是一種通用的技術，經過預先建立必定數量的線程，當有請求達到時，線程池分配一個線程提供服務，請求結束後，該線程又去服務其餘請求。 經過這種方式，避免了線程和內存對象的頻繁建立和釋放，下降了服務端的併發度，減小了上下文切換和資源的競爭，提升資源利用效率。全部服務的線程池本質都是位了提升資源利用效率，而且實現方式也大致相同。本文主要說明Mysql線程池的實現原理。

    在Mysql5.6出現之前，Mysql處理鏈接的方式是One-Connection-Per-Thread,即對於每個數據庫鏈接，Mysql-Server都會建立一個獨立的線程服務，請求結束後，銷燬線程。再來一個鏈接請求，則再建立一個鏈接，結束後再進行銷燬。這種方式在高併發狀況下，會致使線程的頻繁建立和釋放。固然，經過thread-cache，咱們能夠將線程緩存起來，以供下次使用，避免頻繁建立和釋放的問題，可是沒法解決高鏈接數的問題。One-Connection-Per-Thread方式隨着鏈接數暴增，致使須要建立一樣多的服務線程，高併發線程意味着高的內存消耗，更多的上下文切換(cpu cache命中率下降)以及更多的資源競爭，致使服務出現抖動。相對於One-Thread-Per-Connection方式，一個線程對應一個鏈接，Thread-Pool實現方式中，線程處理的最小單位是statement(語句)，一個線程能夠處理多個鏈接的請求。這樣，在保證充分利用硬件資源狀況下(合理設置線程池大小)，能夠避免瞬間鏈接數暴增致使的服務器抖動。

調度方式實現

     Mysql-Server同時支持3種鏈接管理方式，包括No-Threads，One-Thread-Per-Connection和Pool-Threads。No-Threads表示處理鏈接使用主線程處理，不額外建立線程，這種方式主要用於調試；One-Thread-Per-Connection是線程池出現之前最經常使用的方式，爲每個鏈接建立一個線程服務；Pool-Threads則是本文所討論的線程池方式。Mysql-Server經過一組函數指針來同時支持3種鏈接管理方式，對於特定的方式，將函數指針設置成特定的回調函數，鏈接管理方式經過thread_handling參數控制，代碼以下：

1 if (thread_handling <= SCHEDULER_ONE_THREAD_PER_CONNECTION) 2  one_thread_per_connection_scheduler(thread_scheduler, 3                                       &max_connections, 4                                       &connection_count); 5 else if (thread_handling == SCHEDULER_NO_THREADS) 6  one_thread_scheduler(thread_scheduler); 7 else                                 
8   pool_of_threads_scheduler(thread_scheduler, &max_connections,&connection_count); 

 鏈接管理流程

1. 經過poll監聽mysql端口的鏈接請求
2. 收到鏈接後，調用accept接口，建立通訊socket
3. 初始化thd實例，vio對象等
4. 根據thread_handling方式設置，初始化thd實例的scheduler函數指針
5. 調用scheduler特定的add_connection函數新建鏈接

下面代碼展現了scheduler_functions模板和線程池對模板回調函數的實現，這個是多種鏈接管理的核心。

struct scheduler_functions { uint max_threads; uint   *connection_count; ulong *max_connections; bool (*init)(void); bool (*init_new_connection_thread)(void); void (*add_connection)(THD *thd); void (*thd_wait_begin)(THD *thd, int wait_type); void (*thd_wait_end)(THD *thd); void (*post_kill_notification)(THD *thd); bool (*end_thread)(THD *thd, bool cache_thread); void (*end)(void); };

static scheduler_functions tp_scheduler_functions= { 0,                                    // max_threads
 NULL, NULL, tp_init, // init
  NULL,                              // init_new_connection_thread
  tp_add_connection,          // add_connection
  tp_wait_begin,                 // thd_wait_begin 
  tp_wait_end,                   // thd_wait_end
  tp_post_kill_notification,  // post_kill_notification 
  NULL,                             // end_thread
  tp_end                            // end
 };

線程池的相關參數

1. thread_handling:表示線程池模型。
2. thread_pool_size:表示線程池的group個數，通常設置爲當前CPU核心數目。理想狀況下，一個group一個活躍的工做線程，達到充分利用CPU的目的。
3. thread_pool_stall_limit:用於timer線程按期檢查group是否「停滯」，參數表示檢測的間隔。
4. thread_pool_idle_timeout:當一個worker空閒一段時間後會自動退出，保證線程池中的工做線程在知足請求的狀況下，保持比較低的水平。
5. thread_pool_oversubscribe:該參數用於控制CPU核心上「超頻」的線程數。這個參數設置值不含listen線程計數。
6. threadpool_high_prio_mode:表示優先隊列的模式。

線程池實現

上面描述了Mysql-Server如何管理鏈接，這節重點描述線程池的實現框架，以及關鍵接口。如圖1

 

                                                          圖 1(線程池框架圖)

      每個綠色的方框表明一個group，group數目由thread_pool_size參數決定。每一個group包含一個優先隊列和普通隊列，包含一個listener線程和若干個工做線程，listener線程和worker線程能夠動態轉換，worker線程數目由工做負載決定，同時受到thread_pool_oversubscribe設置影響。此外，整個線程池有一個timer線程監控group，防止group「停滯」。

關鍵接口

     1. tp_add_connection[處理新鏈接]

       1)  建立一個connection對象

       2)  根據thread_id%group_count肯定connection分配到哪一個group

       3)  將connection放進對應group的隊列

       4)  若是當前活躍線程數爲0，則建立一個工做線程

    2. worker_main[工做線程]

      1)  調用get_event獲取請求

      2)  若是存在請求，則調用handle_event進行處理

      3)  不然，表示隊列中已經沒有請求，退出結束。

    3. get_event[獲取請求]

     1)  獲取一個鏈接請求

     2)  若是存在，則當即返回，結束

     3)  若此時group內沒有listener，則線程轉換爲listener線程，阻塞等待

     4)  若存在listener，則將線程加入等待隊列頭部

     5)  線程休眠指定的時間(thread_pool_idle_timeout)

     6)  若是依然沒有被喚醒，是超時，則線程結束，結束退出 

     7)  不然，表示隊列裏有鏈接請求到來，跳轉1

   備註：獲取鏈接請求前，會判斷當前的活躍線程數是否超過了

   thread_pool_oversubscribe+1，若超過了，則將線程進入休眠狀態。

  4. handle_event[處理請求]

    1)  判斷鏈接是否進行登陸驗證，若沒有，則進行登陸驗證

    2)  關聯thd實例信息

    3)  獲取網絡數據包，分析請求

    4)  調用do_command函數循環處理請求

    5)  獲取thd實例的套接字句柄，判斷句柄是否在epoll的監聽列表中

    6)  若沒有，調用epoll_ctl進行關聯

    7)  結束

  5.listener[監聽線程]

   1)  調用epoll_wait進行對group關聯的套接字監聽，阻塞等待

   2)  若請求到來，從阻塞中恢復

   3)  根據鏈接的優先級別，肯定是放入普通隊列仍是優先隊列

   4)  判斷隊列中任務是否爲空

   5)  若隊列爲空，則listener轉換爲worker線程

   6)  若group內沒有活躍線程，則喚醒一個線程

  備註：這裏epoll_wait監聽group內全部鏈接的套接字，而後將監聽到的鏈接

  請求push到隊列，worker線程從隊列中獲取任務，而後執行。

 6. timer_thread[監控線程]

   1)  若沒有listener線程，而且最近沒有io_event事件

   2)  則建立一個喚醒或建立一個工做線程

   3)  若group最近一段時間沒有處理請求，而且隊列裏面有請求，則

   4)  表示group已經stall，則喚醒或建立線程

   5）檢查是否有鏈接超時 

  備註：timer線程經過調用check_stall判斷group是否處於stall狀態，經過調用timeout_check檢查客戶端鏈接是否超時。

 7.tp_wait_begin[進入等待狀態流程]

   1)  active_thread_count減1，waiting_thread_count加1

   2）設置connection->waiting= true

   3)  若活躍線程數爲0，而且任務隊列不爲空，或者沒有監聽線程，則

   4)  喚醒或建立一個線程

  8.tp_wait_end[結束等待狀態流程]

   1)  設置connection的waiting狀態爲false

   2)  active_thread_count加1，waiting_thread_count減1

   備註：

   1)waiting_threads這個list裏面的線程是空閒線程，並不是等待線程，所謂空閒線程是隨時能夠處理任務的線程，而等待線程則是由於等待鎖，或等待io操做等沒法處理任務的線程。

   2)tp_wait_begin和tp_wait_end的主要做用是因爲彙報狀態，即便更新active_thread_count和waiting_thread_count的信息。

 9. tp_init/tp_end

    分別調用thread_group_init和thread_group_close來初始化和銷燬線程池 

線程池與鏈接池

     鏈接池一般實如今Client端，是指應用(客戶端)建立預先建立必定的鏈接，利用這些鏈接服務於客戶端全部的DB請求。若是某一個時刻，空閒的鏈接數小於DB的請求數，則須要將請求排隊，等待空閒鏈接處理。經過鏈接池能夠複用鏈接，避免鏈接的頻繁建立和釋放，從而減小請求的平均響應時間，而且在請求繁忙時，經過請求排隊，能夠緩衝應用對DB的衝擊。線程池實如今server端，經過建立必定數量的線程服務DB請求，相對於one-conection-per-thread的一個線程服務一個鏈接的方式，線程池服務的最小單位是語句，即一個線程能夠對應多個活躍的鏈接。經過線程池，能夠將server端的服務線程數控制在必定的範圍，減小了系統資源的競爭和線程上下文切換帶來的消耗，同時也避免出現高鏈接數致使的高併發問題。鏈接池和線程池相輔相成，經過鏈接池能夠減小鏈接的建立和釋放，提升請求的平均響應時間，並能很好地控制一個應用的DB鏈接數，但沒法控制整個應用集羣的鏈接數規模，從而致使高鏈接數，經過線程池則能夠很好地應對高鏈接數，保證server端能提供穩定的服務。如圖2所示，每一個web-server端維護了3個鏈接的鏈接池，對於鏈接池的每一個鏈接實際不是獨佔db-server的一個worker，而是可能與其餘鏈接共享。這裏假設db-server只有3個group，每一個group只有一個worker，每一個worker處理了2個鏈接的請求。

 

                                        圖 2(鏈接池與線程池框架圖)

線程池優化

1.調度死鎖解決

     引入線程池解決了多線程高併發的問題，但也帶來一個隱患。假設，A，B兩個事務被分配到不一樣的group中執行，A事務已經開始，而且持有鎖，但因爲A所在的group比較繁忙，致使A執行一條語句後，不能當即得到調度執行；而B事務依賴A事務釋放鎖資源，雖然B事務能夠被調度起來，但因爲沒法得到鎖資源，致使仍然須要等待，這就是所謂的調度死鎖。因爲一個group會同時處理多個鏈接，但多個鏈接不是對等的。好比，有的鏈接是第一次發送請求；而有的鏈接對應的事務已經開啓，而且持有了部分鎖資源。爲了減小鎖資源爭用，後者顯然應該比前者優先處理，以達到儘早釋放鎖資源的目的。所以在group裏面，能夠添加一個優先級隊列，將已經持有鎖的鏈接，或者已經開啓的事務的鏈接發起的請求放入優先隊列，工做線程首先從優先隊列獲取任務執行。

2.大查詢處理

    假設一種場景，某個group裏面的鏈接都是大查詢，那麼group裏面的工做線程數很快就會達到thread_pool_oversubscribe參數設置值，對於後續的鏈接請求，則會響應不及時(沒有更多的鏈接來處理)，這時候group就發生了stall。經過前面分析知道，timer線程會按期檢查這種狀況，並建立一個新的worker線程來處理請求。若是長查詢來源於業務請求，則此時全部group都面臨這種問題，此時主機可能會因爲負載過大，致使hang住的狀況。這種狀況線程池自己無能爲力，由於源頭多是爛SQL併發，或者SQL沒有走對執行計劃致使，經過其餘方法，好比SQL高低水位限流或者SQL過濾手段能夠應急處理。可是，還有另一種狀況，就是dump任務。不少下游依賴於數據庫的原始數據，一般經過dump命令將數據拉到下游，而這種dump任務一般都是耗時比較長，因此也能夠認爲是大查詢。若是dump任務集中在一個group內，並致使其餘正常業務請求沒法當即響應，這個是不能容忍的，由於此時數據庫並無壓力，只是由於採用了線程池策略，才致使了請求響應不及時，爲了解決這個問題，咱們將group中處理dump任務的線程不計入thread_pool_oversubscribe累計值，避免上述問題。

參考文檔

http://ourmysql.com/archives/1303

http://blog.chinaunix.net/uid-28364803-id-3431242.html

http://www.atatech.org/articles/31833

https://dev.mysql.com/doc/refman/5.6/en/connection-threads.html