MySQL Proxy - 核心篇 核心層篇（Core） Network Core 構建於 socket 處理實現的基礎之上，將 client connection 和 server connection 關聯到一起。 【Connection Life Cycle】 connection 可處於下面 4 種協議基本 phase 之一： connect authentification query disconnect 通過對 plugin 功能的定制實現，可以改變 network core 的默認工作方式，進而獲得如下三種基本 plugin 功能中的一個： plugin-admin 只實現了 listen 方面的功能 client plugins 只實現了 connection 方面的功能 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 之間相互發送數據。
