数据库分库分表中间件选型

2022-03-02 19:44:24

参考：

https://www.cnblogs.com/wangzhongqiu/p/7100332.html

https://zhuanlan.zhihu.com/p/200984092

https://zhuanlan.zhihu.com/p/25166375

分区：对业务透明，分区只不过把存放数据的文件分成了许多小块，例如mysql中的一张表对应三个文件.MYD,MYI,frm。

根据一定的规则把数据文件(MYD)和索引文件（MYI）进行了分割，分区后的表呢，还是一张表。分区可以把表分到不同的硬盘上，但不能分配到不同服务器上。

优点：数据不存在多个副本，不必进行数据复制，性能更高。
缺点：分区策略必须经过充分考虑，避免多个分区之间的数据存在关联关系，每个分区都是单点，如果某个分区宕机，就会影响到系统的使用。

分片：对业务透明，在物理实现上分成多个服务器，不同的分片在不同服务器上

个人感觉跟分库没啥区别，只是叫法不一样而已，值得一提的是关系型数据库和nosql数据库分片的概念以及处理方式是一样的吗？

请各位看官自行查找相关资料予以解答

分表：当数据量大到一定程度的时候，都会导致处理性能的不足，这个时候就没有办法了，只能进行分表处理。也就是把数据库当中数据根据按照分库原则分到多个数据表当中，

这样，就可以把大表变成多个小表，不同的分表中数据不重复，从而提高处理效率。

分表也有两种方案：

1. 同库分表：所有的分表都在一个数据库中，由于数据库中表名不能重复，因此需要把数据表名起成不同的名字。

优点：由于都在一个数据库中，公共表，不必进行复制，处理更简单
缺点：由于还在一个数据库中，CPU、内存、文件IO、网络IO等瓶颈还是无法解决，只能降低单表中的数据记录数。

　　　　　　表名不一致，会导后续的处理复杂（参照mysql meage存储引擎来处理）

2. 不同库分表：由于分表在不同的数据库中，这个时候就可以使用同样的表名。

优点：CPU、内存、文件IO、网络IO等瓶颈可以得到有效解决，表名相同，处理起来相对简单
缺点：公共表由于在所有的分表都要使用，因此要进行复制、同步。

　　　　一些聚合的操作，join,group by,order等难以顺利进行

参考博客：http://www.cnblogs.com/langtianya/p/4997768.html，http://blog.51yip.com/mysql/949.html

分库：分表和分区都是基于同一个数据库里的数据分离技巧，对数据库性能有一定提升，但是随着业务数据量的增加，

原来所有的数据都是在一个数据库上的，网络IO及文件IO都集中在一个数据库上的，因此CPU、内存、文件IO、网络IO都可能会成为系统瓶颈。

当业务系统的数据容量接近或超过单台服务器的容量、QPS/TPS接近或超过单个数据库实例的处理极限等

此时，往往是采用垂直和水平结合的数据拆分方法，把数据服务和数据存储分布到多台数据库服务器上。

分库只是一个通俗说法，更标准名称是数据分片，采用类似分布式数据库理论指导的方法实现，对应用程序达到数据服务的全透明和数据存储的全透明

读写分离方案

海量数据的存储及访问，通过对数据库进行读写分离，来提升数据的处理能力。读写分离它的方案特点是数据库产生多个副本，

数据库的写操作都集中到一个数据库上，而一些读的操作呢，可以分解到其它数据库上。这样，只要付出数据复制的成本，

就可以使得数据库的处理压力分解到多个数据库上，从而大大提升数据处理能力。

1>Cobar 是提供关系型数据库（MySQL）分布式服务的中间件，它可以让传统的数据库得到良好的线性扩展，并看上去还是一个数据库，对应用保持透明。

Cobar以Proxy的形式位于前台应用和实际数据库之间，对前台的开放的接口是MySQL通信协议，将前台SQL语句变更并按照数据分布规则发到合适的后台数据分库，再合并返回结果，模拟单库下的数据库行为。

Cobar属于中间层方案，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，需要做一次转发，而基于JDBC协议并无额外转发，直接由应用程序连接数据库，

性能上有些许优势。这里并非说明中间层一定不如客户端直连，除了性能，需要考虑的因素还有很多，中间层更便于实现监控、数据迁移、连接管理等功能。

Cobar属于阿里B2B事业群，始于2008年，在阿里服役3年多，接管3000+个MySQL数据库的schema,集群日处理在线SQL请求50亿次以上。

由于Cobar发起人的离职，Cobar停止维护。后续的类似中间件，比如MyCAT建立于Cobar之上，包括现在阿里服役的RDRS其中也复用了Cobar-Proxy的相关代码。

2>MyCAT是社区爱好者在阿里cobar基础上进行二次开发，解决了cobar当时存在的一些问题，并且加入了许多新的功能在其中。目前MyCAT社区活跃度很高，

目前已经有一些公司在使用MyCAT。总体来说支持度比较高，也会一直维护下去，发展到目前的版本，已经不是一个单纯的MySQL代理了，

它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。

MyCAT是一个强大的数据库中间件，不仅仅可以用作读写分离，以及分表分库、容灾管理，而且可以用于多租户应用开发、云平台基础设施，让你的架构具备很强的适应性和灵活性，

借助于即将发布的MyCAT只能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表隐射到不同存储引擎上，而整个应用的代码一行也不用改变。

MyCAT是在Cobar基础上发展的版本，两个显著提高：后端由BIO改为NIO，并发量有大幅提高；增加了对Order By, Group By, Limit等聚合功能

（虽然Cobar也可以支持Order By, Group By, Limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）

3>TDDL是Tabao根据自己的业务特点开发了(Tabao Distributed Data Layer, 外号：头都大了)。主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，

它是一个基于集中式配置的jdbc datasourcce实现，具有主备，读写分离，动态数据库配置等功能。

TDDL并非独立的中间件，只能算作中间层，处于业务层和JDBC层中间，是以Jar包方式提供给应用调用，属于JDBC Shard的思想。

TDDL源码：https://github.com/alibaba/tb_tddl
TDDL复杂度相对较高。当前公布的文档较少，只开源动态数据源，分表分库部分还未开源，还需要依赖diamond，不推荐使用。

4>DRDS是阿里巴巴自主研发的分布式数据库服务（此项目不开源）,DRDS脱胎于阿里巴巴开源的Cobar分布式数据库引擎，吸收了Cobar核心的Cobar-Proxy源码，

实现了一套独立的类似MySQL-Proxy协议的解析端，能够对传入的SQL进行解析和处理，对应用程序屏蔽各种复杂的底层DB拓扑结构，获得单机数据库一样的使用体验，

同时借鉴了淘宝TDDL丰富的分布式数据库实践经验，实现了对分布式Join支持，SUM/MAX/COUNT/AVG等聚合函数支持以及排序等函数支持，

通过异构索引、小表广播等解决分布式数据库使用场景下衍生出的一系列问题，最终形成了完整的分布式数据库方案。

5>Atlas是一个位于应用程序与MySQL之间的基于MySQL协议的数据中间层项目，它是在mysql-proxy 0.8.2版本上对其进行优化，360团队基于mysql proxy 把lua用C改写，

它实现了MySQL的客户端和服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节。

Altas不能实现分布式分表，所有的字表必须在同一台DB的同一个DataBase里且所有的字表必须实现建好，Altas没有自动建表的功能。

原有版本是不支持分库分表，目前已经放出了分库分表版本。在网上看到一些朋友经常说在高并发下会经常挂掉，如果大家要使用需要提前做好测试。

6>DBProxy是美团点评DBA团队针对公司内部需求，在奇虎360公司开源的Atlas做了很多改进工作，形成了新的高可靠、高可用企业级数据库中间件

其特性主要有：读写分离、负载均衡、支持分表、IP过滤、sql语句黑名单、DBA平滑下线DB、从库流量配置、动态加载配置项

项目的Github地址是https://github.com/Meituan-Dianping/DBProxy

7>sharding-JDBC是当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问。

Sharding-JDBC是继dubbox和elastic-job之后，ddframe系列开源的第3个项目。

Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零：

可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
可基于任何第三方的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。

Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。

Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。

SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。

知名度较低的：

Heisenberg

Baidu.
其优点：分库分表与应用脱离，分库表如同使用单库表一样，减少db连接数压力，热重启配置，可水平扩容，遵守MySQL原生协议，读写分离，无语言限制，

mysqlclient, c, java都可以使用Heisenberg服务器通过管理命令可以查看，如连接数，线程池，结点等，并可以调整采用velocity的分库分表脚本进行自定义分库表，相当的灵活。

https://github.com/brucexx/heisenberg（开源版已停止维护）

CDS

JD. Completed Database Sharding.
CDS是一款基于客户端开发的分库分表中间件产品，实现了JDBC标准API，支持分库分表，读写分离和数据运维等诸多共，提供高性能，高并发和高可靠的海量数据路由存取服务，

业务系统可近乎零成本进行介入，目前支持MySQL, Oracle和SQL Server.
(架构上和Cobar，MyCAT相似，直接采用jdbc对接，没有实现类似MySQL协议，没有NIO,AIO，SQL Parser模块采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

网易. Distributed DataBase.
DDB经历了三次服务模式的重大更迭：Driver模式->Proxy模式->云模式。

Driver模式：基于JDBC驱动访问，提供一个db.jar, 和TDDL类似，位于应用层和JDBC之间. Proxy模式：在DDB中搭建了一组代理服务器来提供标准的MySQL服务，

在代理服务器内部实现分库分表的逻辑。应用通过标准数据库驱动访问DDB Proxy, Proxy内部通过MySQL解码器将请求还原为SQL, 并由DDB Driver执行得到结果。

私有云模式：基于网易私有云开发的一套平台化管理工具Cloudadmin, 将DDB原先Master的功能打散，一部分分库相关功能集成到proxy中，

如分库管理、表管理、用户管理等，一部分中心化功能集成到Cloudadmin中，如报警监控，此外，Cloudadmin中提供了一键部署、自动和手动备份，版本管理等平台化功能。

OneProxy:

数据库界大牛，前支付宝数据库团队领导楼方鑫开发，基于mysql官方的proxy思想利用c进行开发的，OneProxy是一款商业收费的中间件，楼总舍去了一些功能点，

专注在性能和稳定性上。有朋友测试过说在高并发下很稳定。

Oceanus(58同城数据库中间件)

Oceanus致力于打造一个功能简单、可依赖、易于上手、易于扩展、易于集成的解决方案，甚至是平台化系统。拥抱开源，提供各类插件机制集成其他开源项目，

新手可以在几分钟内上手编程，分库分表逻辑不再与业务紧密耦合，扩容有标准模式，减少意外错误的发生。

Vitess:

这个中间件是Youtube生产在使用的，但是架构很复杂。与以往中间件不同，使用Vitess应用改动比较大要使用他提供语言的API接口，我们可以借鉴他其中的一些设计思想。

Kingshard:

Kingshard是前360Atlas中间件开发团队的陈菲利用业务时间用go语言开发的，目前参与开发的人员有3个左右，目前来看还不是成熟可以使用的产品，需要在不断完善。

MaxScale与MySQL Route:

这两个中间件都算是官方的吧，MaxScale是mariadb (MySQL原作者维护的一个版本)研发的，目前版本不支持分库分表。

MySQL Route是现在MySQL 官方Oracle公司发布出来的一个中间件。

分库分表Sharding-JDBC入门与项目实战

最近项目中不少表的数据量越来越大，并且导致了一些数据库的性能问题。因此想借助一些分库分表的中间件，实现自动化分库分表实现。调研下来，发现Sharding-JDBC目前成熟度最高并且应用最广的Java分库分表的客户端组件。

本文主要介绍一些Sharding-JDBC核心概念以及生产环境下的实战指南，旨在帮助组内成员快速了解Sharding-JDBC并且能够快速将其使用起来。

核心概念

在使用Sharding-JDBC之前，一定是先理解清楚下面几个核心概念。

逻辑表

水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为10张表，分别是t_order_0到t_order_9，他们的逻辑表名为t_order。

真实表

在分片的数据库中真实存在的物理表。即上个示例中的t_order_0到t_order_9。

数据节点

数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。

绑定表

指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。

举例说明,如果SQL为：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

假设t_order和t_order_item对应的真实表各有2个，那么真实表就有t_order_0、t_order_1、t_order_item_0、t_order_item_1。

在不配置绑定表关系时，假设分片键order_id将数值10路由至第0片，将数值11路由至第1片，那么路由后的SQL应该为4条，它们呈现为笛卡尔积：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置绑定表关系后，路由的SQL应该为2条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

广播表

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。

数据分片

分片键

用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。SQL 中如果无分片字段，将执行全路由，性能较差。除了对单分片字段的支持，Sharding-JDBC 也支持根据多个字段进行分片。

分片算法

通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

精确分片算法

对应 PreciseShardingAlgorithm，用于处理使用单一键作为分片键的 = 与 IN 进行分片的场景。需要配合 StandardShardingStrategy 使用。

范围分片算法

对应 RangeShardingAlgorithm，用于处理使用单一键作为分片键的 BETWEEN AND、>、<、>=、<=进行分片的场景。需要配合 StandardShardingStrategy 使用。

复合分片算法

对应 ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合 ComplexShardingStrategy 使用。

Hint分片算法

对应 HintShardingAlgorithm，用于处理通过Hint指定分片值而非从SQL中提取分片值的场景。需要配合 HintShardingStrategy 使用。

分片策略

包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供 5 种分片策略。

标准分片策略

对应 StandardShardingStrategy。提供对 SQ L语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。StandardShardingStrategy 只支持单分片键，提供 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 两个分片算法。

PreciseShardingAlgorithm 是必选的，用于处理 = 和 IN 的分片。RangeShardingAlgorithm 是可选的，用于处理 BETWEEN AND, >, <, >=, <=分片，如果不配置 RangeShardingAlgorithm，SQL 中的 BETWEEN AND 将按照全库路由处理。

复合分片策略

对应 ComplexShardingStrategy。复合分片策略。提供对 SQL 语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。ComplexShardingStrategy 支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

行表达式分片策略

对应 InlineShardingStrategy。使用 Groovy 的表达式，提供对 SQL 语句中的 = 和 IN的分片操作支持，只支持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的Java代码开发，如: t_user_$->{u_id % 8} 表示 t_user 表根据 u_id 模 8，而分成 8 张表，表名称为 t_user_0 到 t_user_7。可以认为是精确分片算法的简易实现

Hint分片策略

对应 HintShardingStrategy。通过 Hint 指定分片值而非从 SQL 中提取分片值的方式进行分片的策略。

分布式主键

用于在分布式环境下，生成全局唯一的id。Sharding-JDBC 提供了内置的分布式主键生成器，例如 UUID、SNOWFLAKE。还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。为了保证数据库性能，主键id还必须趋势递增，避免造成频繁的数据页面分裂。

读写分离

提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。

同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性
基于Hint的强制主库路由。
主从模型中，事务中读写均用主库。

执行流程

Sharding-JDBC 的原理总结起来很简单: 核心由 SQL解析 => 执行器优化 => SQL路由 => SQL改写 => SQL执行 => 结果归并的流程组成。

分库分表中间件DDAL的设计及使用

1. DDAL分层架构设计

DDAL在设计上主要可以分为三层：

最上层为DDALDataSource，用于解析数据源的富客户端(smart client)和轻客户端（light client）的协议实现，目前DDAL实现的是富客户端(smart client)；

<bean name="dataSource" class="org.hellojavaer.ddal.datasource.DefaultDDALDataSource">
    <constructor-arg index="0" value="jdbc:ddal:thick:classpath:/datasource.xml"/>
    <!-- <constructor-arg index="0" value="jdbc:ddal:thick:http://{host}:{port}/{appName}"/> -->
</bean>

中间层为DBClusterManager，用于实现数据库多集群的路由管理，实际中的一个应用场景为应用访问就近数据库集群（需要注意这里定义的集群的含义是每个集群的功能是对等的，而非主从的关系的集群）；
底层为DDRDataSource，它是真正用于实现分库分表路由的组件实现；

基于上图架构的一个完整的工程示例：

hellojavaer/ddal?github.com

另一个简单的读写分离的工程示例

hellojavaer/ddal?github.com

2. DDAL的执行原理

定义分库分表路由规则

<!-- DDAL处理路由规则的一个实现方式是使用EL表达式解析，EL特点是可以使用简单的表达式实现复杂功能 -->
<bean id="idRule" class="org.hellojavaer.ddal.ddr.shard.rule.SpelShardRouteRule">
    <property name="scRouteRule" value="{scName}_{format(‘%02d‘, sdValue % 2)}"/>
    <property name="tbRouteRule" value="{tbName}_{format(‘%04d‘, sdValue % 8)}"/>
</bean>

2.绑定路由规则到逻辑表名或逻辑库（逻辑schema）上，并设置分片字段（也可以不设置分片字段）

<bean class="org.hellojavaer.ddal.ddr.shard.simple.SimpleShardRouteRuleBinding">
    <!-- scName是必选的,scName的路由结果会被用于在数据源管理器中做数据源选择 -->
    <property name="scName" value="base"></property>
    <!-- tbName是可选的,当没有配置tbName时,表示当前路由规则绑定到了当前schema下的所有表 -->
    <!--<property name="tbName" value="user"></property>-->
    <!-- rule是可选的,当没有配置时,解析时直接返回原表名 -->
    <property name="rule" ref="idRule"></property>
    <!-- sdKey是可选的,当没有配置时,通过ShardRouteContext获取路由信息 -->
    <property name="sdKey" value="id"></property>
    <!-- sdValues是可选的,sdValues用于将以上的配置转换为物理表,可用于扫表查询接口 -->
    <property name="sdValues" value="[0..7]"></property>
</bean>

通过这个绑定，可以计算出一个逻辑表名对应的物理表名和一个逻辑库（schema）对应的为物理库（schema）

3. 解析并重写sql

DDAL支持的sql主语法有select，insert，delete，update，支持主语法下的几乎所有sql子语法，包括sub-select,union,exsit, join等

解析sql的过程就是识别sql中的所有表名，如果某一个表名能匹配到步骤2中的逻辑表名，则该表名会根据步骤1中规则进行表名重写，如果没匹配到则不做任何操作，同时所有被重写后的表名会被放在一个结果集用于步骤4数据源的获取。

在重写sql时一个关键的点是获取路由信息，DDAL对分表路由信息的获取分为两大类：

（1）通过sql中的分片值

（2）通过ShardRouteContext；

其中方式（1）优先于方式（2），只有当方式（1）获取失败后才会尝试从方式（2）中获取。而如果两种方式都不能获取到路由信息则会抛出异常，比如：

select * from tb where id = 9

上面的tb匹配了步骤2的绑定，因此会执行表名重写；而id字段又匹配了分片字段，因此会执行方式（1）的分片值重写，重写后的结果为

SELECT * FROM base_01.tb_0001 WHERE id = 9

而如果当sql中不含分片字段或分片字段不能计算路由信息时（比如: id != 9)

select * from tb where WHERE name = ‘test‘

这时可以通过ShardRouteContext设置路由信息

ShardRouteContext.setRouteInfo(‘base‘, 9);

重新后的sql为

SELECT * FROM base_01.tb_0001 WHERE name = ‘test‘

同时DDAL为了简化ShardRouteContext的调用，提供ShardRoute注解进行配置，注解的配置和ShardRouteContext是完全等效的，因为ShardRoute底层使用的就是ShardRouteContext，例如：

 // 当id的值为9时，路由结果的信息完全等同于 ShardRouteContext.setRouteInfo(‘base‘, 9);
 @ShardRoute(scName = "base", sdValue = "{$0}")
 public void test(Long id){}

4.选取数据源并执行

这一步的核心是数据源管理器，它通过将步骤3中计算出的物理库的结果集用于筛选出实际的数据源去执行。而DDAL目前的数据源管理器包含两个：SingleDataSourceManager和DefaultReadWriteDataSourceManager。

SingleDataSourceManager不依赖步骤3计算的物理库结果集，因为它内部只管理了一个数据源，所以不论步骤3返回什么结果集，SingleDataSourceManager都只会把它管理的那一个数据源返回用于sql的执行；

DefaultReadWriteDataSourceManager实现了一个读写分离的数据源管理器，读和写都可以配置多个数据源，读数据源支持配置负载权重。由于内部包含多个数据源因此步骤3的物理库结果集必须至少包含一个结果，用于匹配实际的数据源（如果未匹配中则会抛出异常）

以上完整的配置信息参考以下链接

https://github.com/hellojavaer/ddal/blob/master/ddal-example/ddal-example-example0/src/main/resources/datasource.xml?github.com

3.DDAL对分布式事务的处理

DDAL的设计方向完整的保留数据库ACID的所有特性，在一个数据源连接下的跨schema和跨table操作是允许的（因为底层数据库是支持的）；当出现跨连接操作时，DDAL设计方案是将跨连接的数据进行分组使得分组后的每组数据都在一个连接内。在DDAL中提供的一个实现类是ShardRouteUtils，你可以先使用groupSdValuesByRouteInfo对shard-value进行分组，然后使用groupRouteInfosByDataSource对关联的数据源进行分组。分组后的shard-value再进行操作时每一组的操作就都能完整的保证ACID，不同分组间的操作异常由业务自行进行控制；

4.DDAL分布式主键设计

参考以下链接

hellojavaer：ddal-sequence设计方案?zhuanlan.zhihu.com

5. DDAL特性概览

1. 使用上对业务代码没有任何入侵：只需要代理原有数据源即可实现分表路由功能，DDAL除了依赖jdbc本身的相关api外，不依赖spring,hibernate,mybatis等其他提框架提供的数据访问层的接口和实现；
2. 同时支持单数据源模式和读写组合数据源模式，灵活解决数据库从单一数据库发展到数据集群的不同阶段需要的不同解决方案；
3. 最小程度限制sql：DDAL对sql的限制主要分为两点。1）禁止跨数据源查询，2)分表需要提供分表路由信息；在满足这两点的前提下你的sql几乎是‘*的‘：允许多表jion,允许嵌套子查询,可以对分表字段使用in和between操作以及not操作；（相关设计细节参考DDAL wiki）
4. 分表路由规则配置灵活且简单：分表路由的字段可以是整型也可以是字符型，这里没有任何限制，你可以根据自己的业务规则灵活配置；
5. 支持分表不含分片字段；
6. 支持读写分离；
7. 支持数据源负载均衡配置且可以动态调整：DDAL默认提供了通过MBean动态调节数据库负载的方式，使用上只需要在启动应用后开启jconsole就可以控制各个数据源的负载；
8. 支持无分库分表的普通主从模式：在业务发展的初期，数据库可能并没有做分库分表，但为了提高读性能可能会发展为读写分离的主从模式数据库集群。在这种场景下只需要省略掉分表的配置即可方案实现该业务功能;
9. 支持注解方式的分库分表路由；
10. 支持数据库集群路由
11. 提供分布式主键模块：参考 wiki；