总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 小姐姐味道 「小姐姐养的狗」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

即使是不懂编程的玩家，在对比 NAS 的时候，也会两眼放光，考虑很多因素，比如 RAID 级别、速度、易用程度等。作为时时刻刻与代码打交道的我们，更需要关注数据的存取问题。

一开始，开箱即用的 MySQL，一定是企业的首选。不仅仅因为用的人多，更重要的是生态成熟。要工具有工具，要人有人。对于老板来说，员工看着不爽，可以随时辞退，是一个非常理想的状态。

但是，没有胸怀的老板，干的一定不会长久，因为如果商务会吹、老板会忽悠，业务会飞速发展（虽然现在这种机会比较少了）。对于 MySQL 来说，很快就会遇到问题。

这个时候，就需要一些比只会用 MySQL 级别高一些的人才，来配合老板圆梦。

是时候了，由单机 MySQL 向分布式发展了。

单机 MySQL 面临很多问题。

  1. 单表太大，比如超过 500w，查询就非常吃力
  2. 单库太大，各种资源告急
  3. 读请求太高，严重影响写请求

对此，一堆概念也是腾空而出，比如分库分表、读写分离等。

很长时间以来，国内互联网的做法普遍是采用加入一个中间件的方式来解决，但随着分布式数据库的技术越来越成熟，这些魔法逐渐下沉到它本应该解决的层面--数据库实现层。

留给分库分表技术的时间，已经不多了，它的存量市场越来越少了。分库分表技术，退出历史舞台，也是迟早的事情了。

解决上面三个单机 MySQL 问题，有很多种切入层面。比如，你简单的在 MyBatis 或者 JPA 之上使用 AOP 或者拦截器封装一层，也可以实现，这也是最傻的方式。

再进一步，就可以采用在 JDBC 之上的驱动层来实现，把分库分表的路由维护在内存里，通过重写的 DataSource、Connection、Statment、ResultSet等，对业务进行无侵入的改进。但可惜的是，我们还必须要维护与逻辑表相对应的物理表，而且功能也是阉割的，不确定性依然不小。更要命的是，JDBC 只支持 Java，对于某些公司来说，就非常的不适用。

再就是中间件的传统模式，Proxy。把自己伪装成一个MySQL Server，接受 Client 的请求。至于它后面怎么去操作真实的数据库，你都不需要知道。但 Proxy 本身也是一套服务，你有运维成本在里面，同时功能依然是阉割的。

框架层，驱动层，代理层，在过去很长一段时间里，有无数的互联网公司前赴后继的试水，从 TDDL、Cobar，到 MyCat、ShardingSphere，各种层面的中间件也是层出不穷。但最近几年，这种争相斗艳的场面逐渐不再，到最后剩下来的，也就ShardingSphere这一枝独秀了。

是问题不存在了么？不，正好相反，问题越来越严重。并不是问题消失了，而是它被转化成其他解决方式了。

抛开关系型数据库不说，很久之前，类似于 ElasticSearch、Cassandra这样的 NoSQL 存储，分片和副本的概念，就已经非常成熟了，而且它们是内置的，并不需要 DBA 去人工维护它们的物理位置。

对于关系型数据库来说，走向分布式也终将成为必然。随着 Raft 等协议应用越来越广泛，分布式数据库的可靠性也逐渐得到了保证。如果你以前因为事务问题而拒绝采用某些 NoSQL 产品，那么如今完全兼容 MySQL 的分布式数据库，你没有理由再说 No。

云厂商，直接提供了像Aurora、PolarDB之类的MySQL增强，更有类似 TiDB、OceanBase 这样纯粹的分布式数据库，越来越多的业务走向了这个终途。当你的团队加班加点验证着分库分表中间件的时候，却发现其实换个兼容的存储就能玩得转，你会怎么选，简直不用再多说。

当然，一旦你选用了分布式数据库，以前的 DBA 经验可能就不管用了，比如说索引及其二级索引。你的团队不得不学习新的知识，来应对分布式环境。

但这些都是阵痛，长远看来，分布式数据库是趋势，而分库分表中间件只能吃存量。

当你的业务有了常年累积的复杂数据，你可能会采用复杂的分库分表组件，但如果你的业务比较新，可预见的未来会有大量数据，那一个分布式数据库可能是最合适的。

分库分表中间件并不是消失了。它摇身一变，变成了分布式数据库的一部分。

你可能会听到很多切到分布式数据库，又从分布式数据库切回到 MySQL 的案例，这属于想吃螃蟹但并没有吃到。目前来看，分布式数据库越来越稳定，生态建设也越来越好。而分库分表，则属于存量业务，终将会退出历史的舞台。

文章目录