“分库分表＂ 不注意选型和流程的话

目中创建多个数据源，采用if else的方式，直接根据条件在代码中路由。Spring中有动态切换数据源的抽象类，具体参见

AbstractRoutingDataSource。

如果项目不是很庞大，使用这种方式能够快速的进行分库。但缺点也是显而易见的，需要编写大量的代码，照顾到每个分支。当涉及跨库查询、聚合，需要循环计算结果并合并的场景，工作量巨大。

如果项目裂变，此类代码大多不能共用，大多通过拷贝共享。长此以往，码将不码。

② 框架层

这种情况适合公司ORM框架统一的情况，但在很多情况下不太现实。主要是修改或增强现有ORM框架的功能，在SQL中增加一些自定义原语或者hint来实现。

通过实现一些拦截器(比如Mybatis的Interceptor接口)，增加一些自定义解析来控制数据的流向，效果虽然较好，但会改变一些现有的编程经验。

很多情况要修改框架源码，不推荐。

③ 驱动层

基于在编码层和框架层切入的各种缺点，真正的数据库中间件起码要从驱动层开始。什么意思呢?其实就是重新编写了一个JDBC的驱动，在内存中维护一个路由列表，然后将请求转发到真正的数据库连接中。

像TDDL、ShardingJDBC等，都是在此层切入。



 

 实现层

SQL特殊版本支持，如Mysql cluster本身就支持各种特性，mariadb galera cluster支持对等双主，Greenplum支持分片等。

需要换存储，一般是解决方案，就不在讨论之列了。

技术最终都会趋于一致，选择任何一种、都是可行的。但最终选型，受开发人员熟悉度、社区活跃度、公司切合度、官方维护度、扩展性，以及公司现有的数据库产品等多方位因素影响。选择或开发一款合适的，小伙伴们会幸福很多。

驱动层和代理层对比

通过以上层次描述，很明显，我们选择或开发中间件，就集中在驱动层和代理层。在这两层，能够对数据库连接和路由进行更强的控制和更细致的管理。但它们的区别也是明显的。

驱动层特点

仅支持JAVA，支持丰富的DB

驱动层中间件仅支持Java一种开发语言，但支持所有后端关系

（编辑：淮安站长网）

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