方案选型对比及京东实现方案

说到分布式MySQL的解决方案一般来说解决方案主要就两种，客户端的方案或者中间代理的方案，如图1所示。

图1

这两种方案各有各的优缺点：客户端的方案是指会给业务提供一个专门的客户端的包，这种方案在实现上会更容易一点，如果公司需要快速出一个相对通用的解决方案，客户端的方案可以优先考虑。

客户端方案需要为不同的语言提供不同的客户端的包，这点有所局限。客户端方案只需要走一段网络，理论上性能会更好一点。

客户端方案对业务有侵入，有一些系统部署及实现方面的可能可以控制得更好，但对业务本身不友好，客户端包升级等方面比较麻烦。

中间代理的方案是指采用一个兼容MySQL协议的代理的方式，业务可以使用任何语言的MySQL客户端的包，对业务本身无侵入的，这种方案相对来说是最友好的。

中间代理方案开发难度上来说门槛会更高一点，需要考虑前后端的东西，尤其是与MySQL端交互时自己解析协议的情况下会更复杂一些。中间代理方案多走一段TCP，对性能理论上会有一些影响。

上述两种方案有一个非常重要的因素没有提及，在实际生产环境中面临一个非常现实的问题是MySQL能支持的连接数是有限的。以MySQL5.5来说假设一个MySQL实例配置1000个连接，业务应用实例部署了100个，每个应用实例的数据库连接池配置20个，采用客户端方案这个MySQL实例都没法正常工作了。

大多数情况下并不是每个应用实例的每条连接都是活跃的，中间代理的方案可以很好的解决这个问题，应用实例可以有很多连接打到代理上，代理只需要维护较少的与MySQL的连接即可满足需求，代理与MySQL之间的连接会被业务打过来的访问重复使用。

另外关于多走一次TCP对性能的影响，从我们的实际经验来看其实可以忽略不计，业务实例一多优先遇到的是MySQL连接数的问题，从这个角度来说中间代理的方案会更优。

我们采用的就是中（见图2）。

图2

间代理的方案，京东的分布式MySQL方案由很多部分组成，有JManager、 JProxy、 JTransfer、JMonitor、JConsole、MySQL，在实际部署的时候还涉及到LVS以及域名系统等。

JManager是中心管理节点，这个节点负责统一管理系统的元信息，元信息包括路由信息、权限管理信息、资源相关的信息等。

JProxy就是一个兼容MySQL协议的代理，负责把客户端发送过来的SQL按照路由规则发送到相应的数据库节点上，再把返回的结果进行合并并返回给客户端。JProxy在启动的时候会先去JManager中拉取相关的元信息，并在自己的内存中维护一份，平时使用的时候只用自身内存维护的这一份就可以了。

JProxy的内部实现原理图3所示。

图3

JTransfer是在线迁移系统，我们针对业务的数据进行拆分以后，比如某个MySQL实例上有32个库，等到业务数据量继续增大以后在这个实例上就放不下了，我们就需要往整个集群中加MySQL实例，将之前的32个库中一部分迁移到这个新增加的实例上，如何在不停业务的情况完成数据的在线迁移就是JTransfer这个系统来保证的。

JConsole系统可以理解为将多个业务的中心管理节点整合起来的一个后台管理控制系统，这个系统可以与每个JManager交互。在具体使用的时候，业务方需要申请创建库表、拆分规则、什么权限、对哪些IP授权，我们会通过JConsole系统与JManager交互完成元数据的配置。

JMonitor系统会将各个业务的jproxy以及MySQL相关的信息采集起来，整合到一起形成一个统一的监控系统，完成对系统的全面详尽的监控。