大数据开发：数据库中间件的两种设计方案

在解决大规模数据的存储的问题上，数据库的设计上，开始越来越多地提到和用到中间件，国内外也出现了很多代表性的数据库中间件产品，这些数据库中间节其实不外乎两种设计思路。今天的大数据开发分享，我们就来讲讲，数据库中间件的两种设计方案。

目前来说，市面上典型的数据库中间件设计方案就是两种：Proxy、Smart-client。

数据库中间件的设计原理，其实也很简单。不论是Proxy还是Smart-client，底层都操作了多个数据库实例。不论是分库分表，还是读写分离，都是在数据库中间件层面对业务开发人员进行屏蔽。

1、Proxy模式

独立部署一个代理服务，这个代理服务背后管理多个数据库实例。而在应用中，通过一个普通的数据源(c3p0、druid、dbcp等)与代理服务器建立连接，所有的sql操作语句都是发送给这个代理，由这个代理去操作底层数据库，得到结果并返回给应用。在这种方案下，分库分表和读写分离的逻辑对开发人员是完全透明的。

优点：

①多语言支持。也就是说，不论你用的php、java或是其他语言，都可以支持。

②对业务开发同学透明。由于可以把Proxy当成mysql服务器，理论上业务同学不需要进行太多代码改造，既可以完成接入。

缺点：

①实现复杂。因为Proxy需要实现被代理的数据库server端的通信协议，实现难度较大。

②Proxy本身需要保证高可用。由于应用本来是直接访问数据库，现在改成了访问Proxy，意味着Proxy必须保证高可用。

③租户隔离。可能有多个应用访问Proxy代理的底层数据库，必然会对Proxy自身的内存、网络、cpu等产生资源竞争，Proxy需要需要具备隔离的能力。

2、Smart-client模式

业务代码需要进行一些改造，引入支持读写分离或者分库分表的功能的sdk，这个就是我们的Smart-client。通常Smart-client是在连接池或者driver的基础上进行了一层封装，Smart-client内部与不同的库建立连接。

应用程序产生的sql交给Smart-client进行处理，其内部对sql进行必要的操作，例如在读写分离情况下，选择走从库还是主库；在分库分表的情况下，进行sql解析、sql改写等操作，然后路由到不同的分库，将得到的结果进行合并，返回给应用。

优点：

①实现简单。Proxy需要实现数据库的服务端协议，但是Smart-client不需要实现客户端通信协议。

②天然去中心化。Smart-client的方式，由于本身以sdk的方式，被应用直接引入，随着应用部署到不同的节点上，且直连数据库，中间不需要有代理层。因此相较于Proxy而言，除了网络资源之外，基本上不存在任何其他资源的竞争，也不需要考虑高可用的问题。

缺点：

①通常仅支持某一种语言。例如tddl、zebra、sharding-jdbc都是使用java语言开发，因此对于使用其他语言的用户，就无法使用这些中间件。

②版本升级困难。因为应用使用数据源代理就是引入一个jar包的依赖，在有多个应用都对某个版本的jar包产生依赖时，一旦这个版本有bug，所有的应用都需要升级。

3、代表性的数据库中间件产品

Proxy实现：

阿里巴巴开源的cobar、阿里云上的drds、mycat团队在cobar基础上开发的mycat、mysql官方提供的mysql-Proxy、当当网开源的sharing-sphere等等。

Smart-client实现：

阿里巴巴开源的tddl、大众点评开源的zebra、当当网开源的sharding-jdbc、蚂蚁金服的zal等等。

关于大数据开发，数据库中间件的两种设计方案，以上就为大家做了简单的介绍了。数据库中间件正在成为大数据架构设计当中的重要环节，了解主流的中间件产品，还是很有必要的。