【原创】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 之间相互发送数据。