即使是不懂编程的玩家，在比较NAS时也会眼睛一亮，考虑到RAID级别、速度、易用性等诸多因素。作为一直和代码打交道的我们，需要更加关注数据访问问题。一开始，开箱即用的MySQL肯定是企业的首选。不仅因为用的人多，更重要的是生态成熟。想要工具就需要工具，需要人就需要人。对于老板来说，员工看起来不高兴，随时可以辞退，是一种非常理想的状态。但是，没有心的老板是做不长久的，因为如果业务能吹，老板能糊弄，业务就会发展得很快（虽然现在这样的机会比较少）。对于MySQL，问题很快就会出现。这时候就需要一些比只会MySQL的水平更高的人才来配合老板实现他的梦想。是时候从单机MySQL向分布式发展了。独立的MySQL面临着许多问题。单表太大，比如超过500w，查询非常吃力。单个数据库太大，急需读取各种资源。请求过高，严重影响写请求。为此也空出了一堆概念，比如分库分表，读写分离等。长期以来，国内互联网的做法一般都是通过加一个中间件来解决，但是随着分布式数据库技术越来越成熟，这些魔法逐渐下沉到它应该解决的层面——数据库实现层。分库分表技术剩下的时间不多了，它的存量市场越来越小。分库分表技术退出历史舞台是迟早的事。解决以上三个单机MySQL问题的入门级有很多。比如你可以简单的用AOP或者拦截器在MyBatis或者JPA之上再封装一层，这也是最笨的做法。更进一步，可以通过在JDBC之上使用驱动层实现，在内存中维护分库分表的路由，通过重写DataSource、Connection、Statment、ResultSet、etc.但遗憾的是，逻辑表对应的物理表还是要维护，而且功能也被阉割了，不确定性还是不小。更何况JDBC只支持Java，对于一些公司来说是非常不适用的。然后就是传统的中间件模式，Proxy。将自己伪装成MySQLServer并接受Client的请求。至于背后的真实数据库是如何操作的，就不用知道了。但是Proxy本身也是一套服务，你有运维成本在里面，功能还是被阉割了。框架层、驱动层、代理层，过去很长一段时间，无数互联网公司纷纷试水。从TDDL、Cobar，到MyCat、ShardingSphere，各个层次的中间件也层出不穷。但近年来，这种争奇斗艳的景象逐渐消失，最后只剩下ShardingSphere。问题消失了吗？不，恰恰相反，问题越来越严重。不是问题消失了，而是转化为其他解决方案。抛开关系型数据库，像ElasticSearch、Cassandra这样的NoSQL存储，sharding和replicas的概念早就很成熟了，而且是内置的，不需要DBA去手动维护他们的物理数据。地点。对于关系型数据库，走向分布式终将成为必然。随着Raft等协议的应用越来越广泛，分布式数据库的可靠性逐渐得到了保障。如果你之前因为事务性问题而拒绝采用某些NoSQL产品，那么你没有理由拒绝完全兼容MySQL的分布式数据库。云厂商直接提供Aurora、PolarDB等MySQL增强，以及TiDB、OceanBase等纯分布式数据库。越来越多的企业正走向这一目标。当你的团队加班加点验证分库分表中间件的时候，你发现其实可以玩兼容存储。怎么选，不用多说。当然，一旦你选择了分布式数据库，以前的DBA经验可能就没有用了，比如索引和它们的二级索引。您的团队必须学习新知识来应对分布式环境。但这些都是阵痛。长期来看，分布式数据库是大势所趋，而分库分表中间件只能吃存货。当你的业务有多年积累的复杂数据时，你可能会使用复杂的分库分表组件，但如果你的业务比较新，在可预见的将来会有大量的数据，那么分布式数据库可能是最合适的。分库分表中间件并没有消失。它自我改造，成为分布式数据库的一部分。你可能会听到很多切换到分布式数据库，然后又从分布式数据库切换回MySQL的案例。这是一个想吃螃蟹却得不到的案例。目前分布式数据库越来越稳定，生态建设越来越好。分库分表属于存量业务，终将退出历史舞台。作者简介：品味小姐姐是一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。
