架构师:分库分表就能无限扩容吗?


架构师:分库分表就能无限扩容吗?

作者:莫那鲁道

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

前言

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

前言

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

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

让我们从最初开始。

  1. 单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的,没什么好讲的,基本每个程序员都经历过。

  2. RPC 应用 当业务越来越大,我们需要对服务进行水平扩容,扩容很简单,只要保证服务是无状态的就可以了,如下图:

架构师:分库分表就能无限扩容吗?

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

架构师:分库分表就能无限扩容吗?

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

如果你的公司产品很受欢迎,业务继续高速发展,数据越来越多,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 规则。这样,所有的组件都能保持一致的规则,从而正确的访问到数据库。如下图:

架构师:分库分表就能无限扩容吗?

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

最后

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

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

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


架构师:分库分表就能无限扩容吗?

本篇文章来源于微信公众号:程序IT圈

原创文章,作者:software,如若转载,请注明出处:https://www.sldh123.com/3394.html

(1)
上一篇 8月 22, 2022 1:00 上午
下一篇 8月 24, 2022 1:00 上午

相关推荐

  • 架构师都应该知道的康威定律

    今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前的工作过的公司 eBay、携程、唯品会都是平台型互联网公司,所以今天主要带…

    10月 4, 2022
    650
  • 架构师浅谈服务治理与微服务

    作者:Heaven-Wang来源:blog.csdn.net/suifeng3051 近期都在谈微服务,本人也正在做相关的工作,应领导要求做了一个微服务的分享,本篇文章主要来源于分…

    9月 13, 2022
    440
  • 架构师谈秒杀系统的艺术

    在网上看到一篇讲 12306 抢票的文章,我看完后,觉得文章写很完整。 不仅给出了模拟场景的代码,而且也用压测工具测试了并发情况,是一个很好的学习案例,分享给大家共读。 12306…

    10月 15, 2022
    740
  • MySQL数据库成为瓶颈后,动态数据的查询要如何加速?

    作者:java码哥链接:https://www.jianshu.com/p/064c87b9824e 一般电商系统在完成DB主从分离和分库分表后,可支撑十几万DAU。 DB分了主库…

    9月 9, 2022
    400
  • 有了HTTP,为什么还要RPC?

    作者:赵客缦胡缨v吴钩霜雪明链接:https://www.jianshu.com/p/9d42b926d40d 有了HTTP,为什么还要RPC? RPC:Remote Proced…

    11月 25, 2022
    2280
  • 架构师浅谈缓存的理论与实践

    在 浅谈缓冲区这篇博客中,我们介绍了“缓冲”的相关知识,本文将介绍“缓冲”的孪生兄弟“缓存”。 和缓冲类似,缓存可能是软件中使用最多的优化技术了,比如:在最核心的 CPU 中,就存…

    12月 10, 2022
    520
  • 架构设计—复杂度是不灭的

    与复杂度的斗争是软件开发的一个永恒的主题,我一次又一次地看到它反复出现,并且不断在各个层面上看到有关的争论:到底应该在函数和方法中进行多少注释?理想的抽象是怎样的?一个框架何时开始…

    12月 30, 2022
    340
  • 架构师流程引擎的架构设计

    因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享 1 什么是流程引擎 流程引擎是一个底层支撑平台,是为提供流程处理而开发设计的。流程引擎和流程应用,以及应用程…

    2月 2, 2023
    80
  • 一台服务器最大并发 tcp 连接数多少?65535?

    作者:Java码农链接:https://www.jianshu.com/p/0154dff4be77 首先,问题中描述的65535个连接指的是客户端连接数的限制。 在tcp应用中,…

    9月 9, 2022
    500
  • 架构师聊聊分布式定时任务框架选型

    我们先思考下面几个业务场景的解决方案: 支付系统每天凌晨1点跑批,进行一天清算,每月1号进行上个月清算 电商整点抢购,商品价格8点整开始优惠 12306购票系统,超过30分钟没有成…

    8月 7, 2022
    510

发表回复

您的电子邮箱地址不会被公开。