引言
上一篇讲到了分库分表和分库分表的中间件，这篇就来讲讲怎么选择中间件和分库分表使用的流程。
中间件切入层介绍
如下图，从应用程序到数据大体分为以下五层。
编码层
在同一个项目中创建多个数据源，采用if else的方式，直接根据条件在代码中路由。Spring中有动态切换数据源的抽象类，具体参见AbstractRoutingDataSource。
如果项目不是很庞大，使用这种方式能够快速的进行分库。但缺点也是显而易见的，需要编写大量的代码，照顾到每个分支。当涉及跨库查询、聚合，需要循环计算结果并合并的场景，工作量巨大。
如果项目裂变，此类代码大多不能共用，大多通过拷贝共享。长此以往，码将不码。
框架层
这种情况适合公司ORM框架统一的情况，但在很多情况下不太现实。主要是修改或增强现有ORM框架的功能，在SQL中增加一些自定义原语或者hint来实现。
通过实现一些拦截器（比如Mybatis的Interceptor接口），增加一些自定义解析来控制数据的流向，效果虽然较好，但会改变一些现有的编程经验。
很多情况要修改框架源码，不推荐。
驱动层
基于在编码层和框架层切入的各种缺点，真正的数据库中间件起码要从驱动层开始。什么意思呢？其实就是重新编写了一个JDBC的驱动，在内存中维护一个路由列表，然后将请求转发到真正的数据库连接中。
像TDDL、ShardingJDBC等，都是在此层切入。
包括Mysql Connector/J的Failover协议 (具体指“load balancing”、“replication”、“farbic”等），也是直接在驱动上进行修改。
请求流向一般是这样的：
代理层
代理层的数据库中间件，将自己伪装成一个数据库，接受业务端的链接。然后负载业务端的请求，解析或者转发到真正的数据库中。
像MySQL Router、MyCat等，都是在此层切入。
请求流向一般是这样的：
实现层
SQL特殊版本支持，如Mysql cluster本身就支持各种特性，mariadb galera cluster支持对等双主，Greenplum支持分片等。
需要换存储，一般是解决方案，就不在讨论之列了。
通过以上层次描述，很明显，我们选择或开发中间件，就集中在驱动层和代理层。在这两层，能够对数据库连接和路由进行更强的控制和更细致的管理。但它们的区别也是明显的。
驱动层和代理层对比
驱动层特点
仅支持单语言，支持丰富的DB
一般在驱动层的中间件，就是针对单语言的，比如：sharding-jdbc仅支持java。如果你的开发语言固定，后端数据源类型丰富，推荐使用此方案。
占用较多的数据库连接
驱动层中间件要维护很多数据库连接。比如一个分了10个 库 的表，每个java中的Connection要维护10个数据库连接。如果项目过多，则会出现连接爆炸（我们算一下，如果每个项目6个实例，连接池中minIdle等于5，3个项目的连接总数是 1065*3 = 900 个）。像Postgres这种每个连接对应一个进程的数据库，压力会很大。
数据聚合在业务实例执行
数据聚合，比如count sum等，是通过多次查询，然后在业务实例的内存中进行聚合。
路由表存在于业务方实例内存中，通过轮询或者被动通知的途径更新路由表即可。
集中式管理
所有集群的配置管理都集中在一个地方，运维负担小，DBA即可完成相关操作。
代理层特点
异构支持，DB支持有限
代理层中间件正好相反。仅支持一种后端关系型数据库，但支持多种开发语言。如果你的系统是异构的，并且都有同样的SLA要求，则推荐使用此方案。
运维负担大
代理层需要维护数据库连接数量有限（MySQL Router那种粘性连接除外）。但作为一个独立的服务，既要考虑单独部署，又要考虑高可用，会增加很多额外节点，更别提用了影子节点的公司了。
另外，代理层是请求唯一的入口，稳定性要求极高，一旦有高耗内存的聚合查询把节点搞崩溃了，都是灾难性的事故。
中间件选择
建议聚焦在MyCat和ShardingJDBC上。另外，还有大量其他的中间件，不熟悉建议不要妄动。
数据库中间件不好维护，你会发现大量半死不活的项目。
以下列表，排名不分先后，有几个是只有HA功能，没有拆分功能的：
Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、OneProxy、ArkProxy、Ctrip DAL、Tsharding、vitess、DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、MTDDL、Zebra、Cobar
几个常用的中间件简介
Cobar
Cobar 是提供关系型数据库（MySQL）分布式服务的中间件，它可以让传统的数据库得到良好的线性扩展，并看上去还是一个数据库，对应用保持透明。
Cobar属于阿里B2B事业群，始于2008年，在阿里服役3年多，接管3000+个MySQL数据库的schema,集群日处理在线SQL请求50亿次以上,集群日处理在线数据流量TB级别以上。
Cobar以Proxy的形式位于前台应用和实际数据库之间，对前台的开放的接口是MySQL通信协议，将前台SQL语句变更并按照数据分布规则发到合适的后台数据分库，再合并返回结果，模拟单库下的数据库行为。
Cobar属于中间层方案，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，需要做一次转发，而基于JDBC协议并无额外转发，直接由应用程序连接数据库，性能上有些许优势。这里并非说明中间层一定不如客户端直连，除了性能，需要考虑的因素还有很多，中间层更便于实现监控、数据迁移、连接管理等功能。
由于Cobar发起人的离职，Cobar停止维护。后续的类似中间件，比如MyCAT建立于Cobar之上，包括现在阿里服役的RDRS其中也复用了Cobar-Proxy的相关代码。
MyCAT
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语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）。
sharding-JDBC
sharding-JDBC是当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问(目前已更名为ShardingSphere-JDBC)。
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
- 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
- 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。
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接口，我们可以借鉴他其中的一些设计思想。
分库分表使用注意点
确保数据均衡 拆分数据库的数据尽量均匀，比如按省份分user库不均匀，按userid取模会比较均匀
不用深分页 不带切分键的深分页，会取出所有库所取页数之前的所有数据在内存排序计算。容易造成内存溢出。
减少子查询 子查询会造成SQL解析紊乱，解析错误的情况，尽量减少SQL的子查询。
事务最小原则 尽量缩小单机事务涉及的库范围，即尽可能减少夸库操作，将同类操作的库/表分在一起
特殊函数 distinct、having、union、in、or等，一般不被支持。或者被支持，使用之后会增加风险，需要改造。
分库分表流程与解决方案
无论是采用哪个层面切入进行分库分表，都面临以下工作过程。
信息收集
统计影响的业务和项目
项目范围越大，分库难度越高。有时候，一句复杂的SQL能够涉及四五个业务方，这种SQL都是需要重点关注的。
确定分库分表的规模，是只分其中的几张表，还是全部涉及。分的越多，工作量越大，几乎是线性的。还有一些项目是牵一发动全身的。
确定参与人员
除了分库分表组件的技术支持人员，最应该参与的是对系统、对现有代码最熟悉的几个人。只有他们能够确定哪些SQL该废弃掉、SQL的影响面等。
确定分库分表策略
确定分库分表的维度和切分键。切分键（就是路由数据的column）一旦确定，是不允许修改的，所以在前期架构设计上，应该首先将其确立下来，才能进行后续的工作；数据维度多意味着有不同的切分键，达到不同条件查询的效果。这涉及到数据的冗余（多写、数据同步），会更加复杂。
前期准备
数据规整
库表结构不满足需求，需要提前规整。比如，切分键的字段名称不同或者类型各异。在实施分库分表策略时，这些个性会造成策略过大不好维护。
扫描所有SQL
将项目中所有的SQL扫描出来，逐个判断是否能够按照切分键正常运行。
在判断过程中肯定会有大量不合规的SQL，则都需要给出改造方案，这是主要的工作量之一。
验证工具支持
直接在原有项目上进行改动和验证是可行的，但会遇到诸多问题，主要是效率太低。我倾向于首先设计一些验证工具，输入要验证的SQL或者列表，然后打印路由信息和结果进行判断。
技术准备
建议以下提到的各个点，都找一个例子体验一下，然后根据自己的团队预估难度。以下：
- 中间件所有不支持的SQL类型
- 整理容易造成崩溃的注意事项
- 不支持的SQL给出处理方式
- 考虑一个通用的主键生成器
- 考虑没有切分键的SQL如何处理
- 考虑定时任务等扫全库的如何进行遍历
- 考虑跨库跨表查询如何改造
- 准备一些工具集
实施阶段
数据迁移
分库分表会重新影响数据的分布，无论是全量还是增量，都会涉及到数据迁移，所以Databus是必要的。一种理想的状态是所有的增删改都是消息，可以通过订阅MQ进行双写。但一般情况下，仍然需要去模拟这个状态，比如使用Canal组件。
充足的测试
分库分表必须经过充足的测试，每一句SQL都要经过严格的验证。如果有单元测试或者自动化测试工具，完全的覆盖是必要的。一旦有数据进行了错误的路由，尤其是增删改，将会创造大量的麻烦。在测试阶段，将验证过程输出到单独的日志文件，充足测试后review日志文件是否有错误的数据流向。
SQL复验
强烈建议统一进行一次SQL复验。主要是根据功能描述，确定SQL的正确性，也就是通常说的review。
演练
在非线上环境多次对方案进行演练，确保万无一失。
制定新的SQL规范
分库分表以后，项目中的SQL就加了枷锁，不能够随意书写了。很多平常支持的操作，在拆分环境下就可能运行不了了。所以在上线前，涉及的SQL都应该有一个确认过程，即使已经经过了充足的测试。
结语
分库分表是战略性的技术方案，很多情况无法回退或者回退方案复杂。如果要拆分的库表涉及多个业务方，公司技术人员复杂，CTO要亲自挂帅进行协调，并有专业仔细的架构师进行监督。没有授权的协调人员会陷入尴尬的境地，导致流程失控项目难产。
