【原創】MySQL Proxy - 核心篇

核心層篇（Core）  

      Network Core 構建於 socket 處理實現的基礎之上，將 client connection 和 server connection 關聯到一塊兒。   

【Connection Life Cycle】  

connection 可處於下面 4 種協議基本 phase 之一：  

• connect
• authentification
• query
• disconnect

       經過對 plugin 功能的定製實現，能夠改變 network core 的默認工做方式，進而得到以下三種基本 plugin 功能中的一個：  

1. plugin-admin 只實現了 listen 方面的功能
2. client plugins 只實現了 connection 方面的功能
3. plugin-proxy 實現了上述兩方面的功能

   
【Scripting】  

       源碼中所提供的 plugin 都實現了相應的 callback 功能函數，並將其暴露給了 scripting 層。   就目前而言，scripting 層的功能是由 Lua 語言提供的 -- 這是一種簡單、快速和便於嵌入的腳本語言。  
      咱們經過將大部份內部數據暴露給 scripting 層的方式，令相應模塊函數能夠對傳進 scripting 層的數據進行操做。  


【Network Core Layer】  

       MySQL Proxy 的網絡引擎的設計目標是同時處理數以千計的 connection ，並打算將其用於 load-balancing 和 fail-over 處理，因此其必須可以在同時存在不少 MySQL backend server 的狀況下，對 connection 進行優雅地處理。目標鎖定在了 5k 到 10k 的 connection 數量上。  


       一直到 MySQL Proxy 0.7 版本，MySQL Proxy 使用都是純粹的事件驅動、非阻塞網絡模型。  

      基於事件驅動的設計決定了 MySQL Proxy 對 idling connection 僅會保存少許必要信息：即僅僅保存 connection 的狀態，而後讓其等待事件的到來。  


【Threaded Scripting】  

       一般腳本都是精巧的，並只被用於作一些簡單的決策處理，而把大部分工做交由網絡層處理。  
       在將來的 0.9 版本中，將會利用腳本層中所支持的多線程模型，從而達到以線程池形式呈現的多腳本線程同時運行的效果。  
         如此，腳本層就能夠調用阻塞或者慢函數，而不須要打斷其餘 connection 的執行。  


       對全局 plugin mutex 的 lift，意味着咱們將必須以不一樣的方式對全局結構進行訪問。因爲大多數的訪問出如今 connection level 上（也就是 event-threading 的那層），故只有對相似 "proxy.global.*" 的全局結構進行訪問時才須要保持同步。基於這方面的需求，咱們將研究如何在各個獨立的 Lua-states 之間相互發送數據。