数据库中间件

概述

数据库中间件的主要作用是向应用程序开发人员屏蔽读写分离和分库分表面临的挑战，并隐藏底层实现细节，使得开发人员可以像操作单库单表那样去操作数据。

单个库的应用架构

在操作单库单表的情况下，直接在应用中通过数据连接池(connection pool)与数据库建立连接，进行读写操作。

使用数据库中间件的架构

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

客户端代理：
业务代码需要进行一些改造，引入支持读写分离或者分库分表的功能的sdk，这个就是smart-client。通常smart-client是在连接池或者driver的基础上进行了一层封装，smart-client内部与不同的库建立连接。应用程序产生的sql交给smart-client进行处理，其内部对sql进行必要的操作，例如在读写分离情况下，选择走从库还是主库；在分库分表的情况下，进行sql解析、sql改写等操作，然后路由到不同的分库，将得到的结果进行合并，返回给应用。

数据库拆分

1. 垂直拆分

垂直拆分，指的是将一个包含了很多表的数据库，根据表的功能的不同，拆分为多个小的数据库，每个库包含部分表。关于垂直拆分，还有另一种说法，将一个包含了很多字段的大表拆分为多个小表，每个表包含部分字段，这种情况在实际开发中基本很少遇到。

垂直拆分的另一个典型应用场景是服务化(SOA)改造。在服务化的背景下，除了业务上需要进行拆分，底层的存储也需要进行隔离。垂直拆分会使得单个用户请求的响应时间变长，原因在于，在单体应用的场景下，所有的业务都可以在一个节点内部完成，而垂直拆分之后，通常会需要进行RPC调用。然后虽然单个请求的响应时间增加了，但是整个服务的吞吐量确会大大的增加。

垂直拆分如图，将db_eshop库，拆分为db_user库和db_product库。：

2. 读写分离

即一个 Master 节点(主库)对应多个 Salve 节点(从库)。更新数据时，应用将数据写入master主库，主库将数据同步给多个slave从库。当查询数据时，应用选择某个slave节点读取数据，实现了读能力的扩展。

3. 分库分表（sharding，水平分区）

水平分表从具体实现上又可以分为3种：只分表、只分库、分库分表。分库分表就是实现了写能力的水平扩展。