京东云总监带你吃透分布式精髓(含视频)

首先客户端方案，可以以友商开源的项目称为TDDL为代表，方案思路较为清晰。如果我们自身需要做一个分布式系统的话，将分布式解决方案放入客户端内，最重要的就是“告诉”客户端SQL语句应该链接到背后哪个数据库，毕竟不同的数据存储在不同的机器当中。对于客户端的方案，比较重要的就是与后端的一些连接，以及如何解析这个SQL语句。

第二种方案就是Proxy方案。Proxy方案相对客户端方案而言，开发难度稍微高一些，但思路上还是非常一致的。举例说明，一张用户表，用户表的组件是ID，我们对ID的分布式key进行分布，查询具体某一个用户ID的时候其实就有一个Proxy，如果说查询这个用户ID为0，进而就知道0是存在于后台的哪一台MySQL。

所以对于Proxy而言，非常重要的一点还是需要去解析具体的SQL语句，这个过程中必须需要有一个自己的路由，就可以完成识别。

客户端的方案与Proxy方案的区别在哪里?区别在于客户端的方案开发起来相对比较简单一点，在JDBC中或者要求客户端调用时，客户端可以不解析SQL语句，完成导向很容易。

对于Proxy方案，它需要兼容原有的MySQL协议，怎么建立MySQL连接，怎么与后端保持连接，这个难度比较大。但相对而言，Proxy方案的限制也比较多，不管是客户端的表层方案，还是Proxy的表层方案，它们对SQL的使用要求都是比较高的，例如一些join是比较难支持的，而且要与业务方达成一致。

此外，无论是客户端方案还是Proxy方案，整体架构还是比较类似的。例如Proxy方案，它会涉及前端如何与客户端进行连接以及后端的Backend connection，还要与后端真正提供MySQL服务的保持连接，这是两个连接的管理。

经过了解，整个Proxy一般的设计都会采取无状态，因为路由信息都是保存在Proxy本机的;但路由方面肯定有一个相对的路由管理中心去分发和更改控制。业界大部分Proxy设计，大家都会发现，Proxy代理的方案其架构设计非常相像，区别在于工程质量不同而已。

另外，对于Proxy方案的缺点就是怎么去做一个分布式事务，没办法保证次序。通常在一个分布式的情况下，其实很难保证每个节点上的事务执行是按照我们想像中的次序去做。

讲完表层的解决方案之后，我们还需要讲讲比较深层次的底层解决方案。从表层出发，不管是客户端方案还是Proxy方案，都并没有去改变底层MySQL的整体协议，也没有改变数据库原生服务，可以认为根本就没有让MySQL底层代码发生变动。

如今可知晓的底层解决方案主要有三个，第一个方案是块存储方案，包括SAN解决方案，涉及云端就是云硬盘解决方案，都是同一类型的。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!