• 分库分表就能无限扩容么?


    单体应用

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

    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请求的数据库一定是在这个应用的。

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

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

    原文链接:https://mp.weixin.qq.com/s/BSKOd5H_PxJRHmqT5MBuUA

  • 相关阅读:
    排查程序死循环,死锁的方法 ——pstack
    可变参数使用
    snprintf 返回值陷阱 重新封装
    linux 查看cpu个数,内存情况,系统版本
    nginx取结构体地址
    fuser命令使用心得
    Linux中dos2unix批量转换
    rpm中config,config(noreplace)区别
    slowhttptest慢攻击工具介绍
    jmeter性能测试
  • 原文地址:https://www.cnblogs.com/liushiqiang123/p/11054460.html
Copyright © 2020-2023  润新知