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