【原创】MySQL Proxy - 核心篇-阿里云开发者社区

开发者社区> 数据库> 正文

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章