除了 NoSQL 的另外一种流派是怎么做的呢？这种流派就是在传统的关系型数据库的基础上去探索基于Proxy或者中间件的方案。下面所有这些就统称为Proxy了，这是一类的分库分表的方案。

它相比 NoSQL 放弃了一些传统数据库的特性，传统的数据库领域的开发者也在摸索怎么通过尽量保持原有特性的方式解决这个问题，有两个比较重要的方向，一个是 Scale Up，一个是Scale Out。

说到 Scale Up，就不得不提 Oracle，Oracle 典型的方案是 Oracle RAC 。通过共享存储的硬件方案解决集群问题，也就是大家常说的 Scale Up 方案，这种方案除了比较大的成本问题，扩展方面也不是太灵活，需要提前预估好大概的容量，以及今后的可能增长的容量，而且节点数太多的时候会带来比较严重的征用问题。

那么在 MySQL 这个相比于 Oracle 更活跃的开源社区的话，他们是怎么做的呢？MySQL Proxy 和中间件 Middleware ，严格来说这也是一种分布式的方案，也就是大家经常讨论的 Scale Out 的方案，只不过这种分布式方案带有一定妥协，主要的原理是通过业务上指定的Sharding Key ，当然这个 Sharding Key 是可以组合的。将数据进行分片，国内在这个领域有过很多闭源和开源的项目，甚至每家比较大的公司都会自己搞一套，比如阿里的Cobar、TDDL，后来社区基于Cobar改进的MyCAT，360开源的Atlas，金山的 Kingshard， Youtube的Vitess等都属于这一类，基本上可以认为是 NewSQL 类产品出现之前业界最好的解决方案了，包括 Google 在很长一段时间，其广告系统也采用的是 MySQL Proxy 的方案。

但是这种方案也不是最完美的，它也有很多的问题，从两个方面来看：

首先是数据分布问题，前面已经说了，MySQL Proxy 会通过 Sharding Key 把数据进行 Hash，存储在不同的数据库分片上，这个方案的假设就是，我的 Sharding Key 维度之间是相互独立的，举一个电商的例子如果以卖家 UserID 作为 Sharding Key，存储卖家购买商品的信息，MySQL Proxy 的方案希望 User 和 User 之间是相互独立的，没有依赖关系。这种做法实际上限制了业务场景，比如说我们可能有一个需求，统计下当天既买了分片 1 上面的卖家 A 又买了分片 3 上面卖家 B 的买家信息，这种业务需求就涉及到横跨不同数据库分片，需要进行一些聚合操作，MySQL Proxy 的方案就不能很好地支持了。

还有一个问题是跨不同数据库分片的分布式事务问题，简单来说，就是要么保证所有的数据库分片要么全部成功，要么全部失败。典型的比如转账操作，比如说我转给谁多少钱，如果中间出现了我的钱少了，他的钱没加，或者说其他的不同的情况，都是错误的情况。因为 MySQL Proxy 底层数据真正存储的实际上是不同的 MySQL 实例，很难去保证跨不同数据库分片之间一致性的操作的问题。这种方案在解决分布式事务方面是有问题的，当然可以通过外部增加类似一个事务管理器的方式，但又会引入额外的问题，这里不展开讨论。当然这个方法最大的问题就是很难保证不停机操作，特别是在扩容的过程中，如果遇到分片数据校验失败或者某个节点出现 Crash 等异常场景，就会处于一个非常糟糕的中间状态，让运维变得非常的复杂，甚至容易出错，增加了很多的新的负担。

从另外一个维度去看这个架构的问题，讨论完数据分布，我们再来看看数据复制方面的情况。有一句话说的比较中肯，在分布式领域里面，最核心的问题就是数据的一致性问题。MySQL Proxy 这个方案里面，其实最直观的体现就是在数据复制方面。MySQL Proxy 主要解决的问题就是数据分片的逻辑管理问题。我们也提到了最底层的数据分片还是存储在 MySQL 数据库实例中，使用的是传统的 Master-Slave 的主从复制方式。这种数据复制方式默认是异步的方式，当然可以选择使用半同步的数据复制方式，但也没有解决所有的问题。如果业务并发量比较大，同步的流量比较大，依然会退化成异步的复制方式。为了让大家更好的理解这个问题，做了一个图：