扎心一问：分库分表就能无限扩容吗

前言

像我这样的菜鸟，总会有各类疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工做几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？实际上是老生常谈的话题：服务的扩容问题。

正常状况下的服务演化之路

让咱们从最初开始。

1. 单体应用 每一个创业公司基本都是从相似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每一个程序员都经历过。
2. RPC 应用 当业务愈来愈大，咱们须要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就能够了，以下图：

当业务又愈来愈大，咱们的服务关系错综复杂，同时，有不少服务访问都是不须要链接 DB 的，只须要链接缓存便可，那么就能够作成分离的，减小 DB 宝贵的链接。以下图：

我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。

3. 分库分表

若是你的公司产品很受欢迎，业务继续高速发展，数据愈来愈多，SQL 操做愈来愈慢，那么数据库就会成为瓶颈，那么你确定会想到分库分表，不论经过 ID hash 或者 range 的方式均可以。以下图：

这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就能够了。

这也是本文的标题，分库分表就能解决无限扩容吗？

实际上，像上面的架构，并不能解决。

其实，这个问题和 RPC 的问题有点相似：数据库链接过多！！！

一般，咱们的 RPC 应用因为是使用中间件进行访问数据库，应用其实是不知道到底要访问哪一个数据库的，访问数据库的规则由中间件决定，例如 sharding JDBC。这就致使，这个应用必须和全部的数据库链接，就像咱们上面的架构图同样，一个 RPC 应用须要和 3 个 mysql 链接，若是是 30 个 RPC 应用，每一个 RPC 的数据库链接池大小是8 ，每一个 mysql 须要维护 240 个链接，咱们知道，mysql 默认链接数是 100，最大链接数是 16384，也就是说，假设每一个应用的链接池大小是 8 ，超过 2048 个应用就没法再继续链接了，也就没法继续扩容了。注意，因为每一个物理库有不少逻辑库，再加上微服务运动如火如荼， 2048 并无看起来那么大。

也许你说，我能够经过前面加一个 proxy 来解决链接数的问题，实际上，代理的性能也会成为问题，为何？代理的链接数也是不能超过 16384 的，若是并发超过 16384，变成 163840，那么 proxy 也解决不了问题。

怎么办？让咱们再看看上面的架构图：

咱们发现，问题是出在“每一个 RPC 应用都要连全部的库”，致使扩容应用的同时，每一个数据库链接数就要增长。就算增长数据库，也不能解决链接数的问题。

那怎么办呢？

单元化

单元化，听起来高大上，一般在一些 XXX 大会上，分享“关于两地三中心”，“三地五中心”，“异地多活”等等牛逼的名词的时候，单元化也会一块儿出现。

这里咱们不讨论那么牛逼的，就只说“数据库链接数过多” 的问题。

实际上，思路很简单：咱们不让应用链接全部的数据库就能够了。

假设咱们根据 range 分红了 10 个库，如今有 10 个应用，咱们让每一个应用只连一个库，当应用增多变成 20个，数据库的链接不够用了，咱们就将 10 个库分红 20 个库，这样，不管你应用扩容到多少个，均可以解决数据库链接数过多的问题。

注意：作这件事的前提是：你必须保证，访问你这个应用的 request 请求的数据库必定是在这个应用的。s

换个说法，当用户从 DNS 那里进来的时候，就知道本身要去那个应用了，因此，规则在 DNS 以前就定好了，虽然这有点夸张，但确定在进应用以前就知道要去哪一个库了。

因此，这一般须要一个规则，例如经过用户 ID hash，由配置中心广播 hash 规则。这样，全部的组件都能保持一致的规则，从而正确的访问到数据库。以下图：

到这里，咱们终于解决了无限扩容的问题。

最后

本文从单体应用开始，逐步讲述了一个正常后台的演进历程，知道了分库分表并不能解决“无限扩容” 的问题，只有单元化才能解决这问题。而单元化则带来更多的复杂性。可是好处不言而喻。

单元化带来的更多的思路。

有了单元化，解决了无限扩容的问题，可是咱们尚未考虑单点的问题，即服务的可用性。要知道，咱们这里的数据库都是单点的。

这就是另外一个话题 —— 异地多活。限于篇幅，下次再聊。