嚣张：分库分表就能无限扩容吗？

谁借莪１个温暖的怀抱￠ 2022-10-04 14:53 147阅读 0赞

![ccb42ababb2604d8fc225884d1543ab2.png][]

作者：莫那鲁道

来源：thinkinjava.cn/2019/01/fkfb/

**前言**

*   *  正常情况下的服务演化之路
 *  单元化
 *  最后

# 前言    #

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

## 正常情况下的服务演化之路 ##

让我们从最初开始。

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

![8a3fda39d4fc166b620425da6048db6a.png][]

当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图：

![56a5e0b1329b1a25b421a0476ac41c1e.png][]

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

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

![fb71a6bc154f9832d2f58eb3aee00473.png][]

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

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

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

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

搜索公众号后端架构师回复关键字“面试”，获取一份惊喜礼包。

通常，我们的 RPC 应用由于是使用中间件进行访问数据库，应用实际上是不知道到底要访问哪个数据库的，访问数据库的规则由中间件决定，例如 sharding JDBC。这就导致，这个应用必须和所有的数据库连接，就像我们上面的架构图一样，一个 RPC 应用需要和 3 个 mysql 连接，如果是 30 个 RPC 应用，每个 RPC 的数据库连接池大小是8 ，每个 mysql 需要维护 240 个连接，我们知道，mysql 默认连接数是 100，最大连接数是 16384，也就是说，假设每个应用的连接池大小是 8 ，超过 2048 个应用就无法再继续连接了，也就无法继续扩容了。

注意，由于每个物理库有很多逻辑库，再加上微服务运动如火如荼， 2048 并没有看起来那么大。

也许你说，我可以通过前面加一个 proxy 来解决连接数的问题，实际上，代理的性能也会成为问题，为什么？代理的连接数也是不能超过 16384 的，如果并发超过 16384，变成 163840，那么 proxy 也解决不了问题。

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

![4fa569c4a980cd2fa2eec325f8c6bfe4.png][]

我们发现，问题是出在“每个 RPC 应用都要连所有的库”，导致扩容应用的同时，每个数据库连接数就要增加。就算增加数据库，也不能解决连接数的问题。

那怎么办呢？

# 单元化 #

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

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

实际上，思路很简单：我们不让应用连接所有的数据库就可以了。

假设我们根据 range 分成了 10 个库，现在有 10 个应用，我们让每个应用只连一个库，当应用增多变成 20个，数据库的连接不够用了，我们就将 10 个库分成 20 个库，这样，无论你应用扩容到多少个，都可以解决数据库连接数过多的问题。

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

换个说法，当用户从 DNS 那里进来的时候，就知道自己要去那个应用了，所以，规则在 DNS 之前就定好了，虽然这有点夸张，但肯定在进应用之前就知道要去哪个库了。

所以，这通常需要一个规则，例如通过用户 ID hash，由配置中心广播 hash 规则。这样，所有的组件都能保持一致的规则，从而正确的访问到数据库。如下图：

![45a30d0698abf73a680f7ac697a3f5ae.png][]

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

# 最后 #

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

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

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

往期推荐

[Netty 实现百万连接的难点和优化点][Netty]

[面试官：说一下线程池内部工作原理？][Link 1]

[产品需求：用java做一个长链接转短链的微服务][java]

[【elasticsearch】数据早8小时or晚8小时，你知道为什么吗？附解决方案][elasticsearch_8_or_8]

[java项目，这样优雅的处理 Exception 实践，客户都给你点赞][java_ Exception]

[大实话：等电梯的时候，90%的程序员都想过调度算法][90]

[SpringBoot实现API接口多版本支持][SpringBoot_API]

[太多项目使用MyBatis，你理解它的架构和原理吗？][MyBatis]

![6ae4d4fb8c1f673d8611d888da1a88f1.gif][]

[ccb42ababb2604d8fc225884d1543ab2.png]: /images/20221004/766ab18ac94a4d1e864d2796511dafe9.png
[8a3fda39d4fc166b620425da6048db6a.png]: /images/20221004/a203bd3c07a942358910d620c213fd02.png
[56a5e0b1329b1a25b421a0476ac41c1e.png]: /images/20221004/c7c3c4d5554043ea8d66646bde45e460.png
[fb71a6bc154f9832d2f58eb3aee00473.png]: /images/20221004/ebc00540ccd34fdf9988947c4c9da52c.png
[4fa569c4a980cd2fa2eec325f8c6bfe4.png]: /images/20221004/ae847b2df11540819b6e869002d103d8.png
[45a30d0698abf73a680f7ac697a3f5ae.png]: /images/20221004/0b96ce4096aa40ceb51b4481e309931f.png
[Netty]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ecb4cb3365a2979fbbea11a03340913ee614c594a8a9b767a04aac0a2e982cf72f0cbb4d&idx=1&mid=2247489933&scene=21&sn=f7e9029d3ac5ccf07e723daeaa9f7701#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ecb4cb3365a20848dbd7c70bdc538bb904e2d92a408dfaba2e3c0445bb031aa39de8e413&idx=2&mid=2247489933&scene=21&sn=546277dbe1ed85f7f74c7a22c783e8a5#wechat_redirect
[java]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec4ecb336558c4ab1ea71982984ca0935fa355b23707e2dbbf38e48b88ea29d0387f8195&idx=1&mid=2247489911&scene=21&sn=fd587cc24b56b4c79431c6efe3ee64c3#wechat_redirect
[elasticsearch_8_or_8]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec4ecb3365583d1edd3cf070cedbc443439b0fce6a6ef70b25169fad51dbb3385edb7444&idx=2&mid=2247489911&scene=21&sn=b22411aea5b6f4660e200d6f53f7b467#wechat_redirect
[java_ Exception]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec73cb3365658ea7013c5e2c0e35fb8acc9d03b7b43c5015bcab1c4b467d87e6eaebac7e&idx=1&mid=2247489866&scene=21&sn=0a45b43ef5c24ec3ce852e973bef1c59#wechat_redirect
[90]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec7bcb33656d274611e70048cfba05ae34ae2382d84aae01e9fcdfb30a1e4dad7bcd5153&idx=2&mid=2247489858&scene=21&sn=5a2bf75e333fba2d67bb4a043d421088#wechat_redirect
[SpringBoot_API]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec2acb33653c3fda67373cddeba16cb07c7baf87d3e879a494e486f3a4eacb74ba68a3e8&idx=1&mid=2247489811&scene=21&sn=6029b7b8d82753efa260d0c7ee093a3d#wechat_redirect
[MyBatis]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44ec36cb3365201cf9fdaaf57be38c72de39612cc07b9f2de2eeb1e9c13512140b9ffe01c1&idx=1&mid=2247489807&scene=21&sn=11a0903158c30553a8d4ee7664ff13c7#wechat_redirect
[6ae4d4fb8c1f673d8611d888da1a88f1.gif]: /images/20221004/47cff710d8474cc2a0f792d84536824b.png