专栏首页数据和云分库分表就能无限扩容吗,解释得太好了!

分库分表就能无限扩容吗,解释得太好了!

作者:莫那·鲁道

前言


我们在工作中会有各种疑问,刚开始是对 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 请求的数据库一定是在这个应用的。

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

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

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

最后


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

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

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

原文:http://thinkinjava.cn/2019/01/fkfb/


另:想了解更多数据库的知识与用法,欢迎关注墨天轮“数据库专栏”(地址:https://www.modb.pro/db,或者扫描下方二维码可直达),此外,墨天轮开放了很多数据库专栏,如 GaussDB、PolarDB、OceanBase、TDSQL、GoldenDB 等众多数据库专栏,欢迎关注学习!

推荐阅读:2020年1月数据库流行度排行:从万里挑二到波澜不惊

数据和云

ID:OraNews

如有收获,请划至底部,点击“在看”,谢谢!

资源下载

关注公众号:数据和云(OraNews)回复关键字获取

help,30万+下载的完整菜单栏

2019DTCC,数据库大会PPT

2018DTCC , 数据库大会PPT

2018DTC,2018 DTC 大会 PPT

ENMOBK,《Oracle性能优化与诊断案例》

DBALIFE,“DBA 的一天”海报

DBA04,DBA 手记4 电子书

122ARCH,Oracle 12.2体系结构图

2018OOW,Oracle OpenWorld 资料

产品推荐

云和恩墨BethuneX 企业版,集监控、巡检、安全于一身,你的专属数据库实时监控和智能巡检平台,漂亮的不像实力派,你值得拥有!

云和恩墨zData一体机现已发布超融合版本和精简版,支持各种简化场景部署,零数据丢失备份一体机ZDBM也已发布,欢迎关注。

云和恩墨大讲堂 | 一个分享交流的地方

长按,识别二维码,加入万人交流社群

请备注:云和恩墨大讲堂

你的“在看”,能被看见

本文分享自微信公众号 - 数据和云(OraNews),作者:莫那·鲁道

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 为什么说云数据库是商业的成功、技术的倒退?

    我们在越来越多的会议、媒体、文章、报道上看到一种说法:“未来的数据库是云数据库的时代,云数据库厂商终将取代传统数据库厂商”。首先我并不否认这种说法,但是云数据库...

    数据和云
  • 2019年开源数据库报告发布:MySQL仍卫冕!

    墨墨导读:3月初,ScaleGrid发布了数据库趋势报告:SQL打败NoSQL,MySQL最受欢迎。

    数据和云
  • 平安科技汪洋:云数据库的前世今生

    2019数据技术嘉年华于11月16日在京落下了帷幕。大会历时两天,来自全国各地上千名学术精英、数据库领袖人物、数据库专家、技术爱好者在这里汇聚一堂,围绕“开源 ...

    数据和云
  • 数据库中的元数据

    刘耀铭同学元数据系列作品的第三篇,大家支持! 今天跟大家谈谈数据库中的元数据 数据库中的元数据无非就是对数据库中数据的描述与定义。 ? 我们先举个现实生活中...

    大数据和云计算技术
  • Redis数据库详解

    在Redis中,我们在使用相关命令时实际上是在默认的数据库中执行的,因为在Redis中是有很多个数据库的,不同数据库与数据库之间数据是不同步的,那么在这一篇中,...

    吉林乌拉
  • (文中有惊喜)走进云时代的数据库

    最近几年,随着云计算相关技术的发展,各种不同类型的云层出不穷,服务越来越多不同类型的企业业务,传统企业也渐渐开始探索上云的道路。在云上,作为业务最核心的数据库,...

    数据和云
  • 数据库简史 4 下一代数据库

    国庆节前最后一篇, 前几期从国外数据库历史, 国内数据库历史, 搞笑数据库捡屎, 国庆节前也不能闲着.最近在看一本书, 关于下一代数据库.

    AustinDatabases
  • 数据库简介

       数据库是一个以某种有组织的方式存储的数据集合。理解数据库的一种最简单的办法是将其想象为一个文件柜。此文件柜是一个存放数据的物理位置,不管数据是什么以及如何...

    Demo_Null
  • 数据库漫游指南

    “文艺复兴以降,源远流长的科学精神和逐步形成的学术规范......你们这一脸迷茫的看着我,不知道我在说什么吗?这是机械工业出版社的前言!多么经典的书,回去好好看...

    Apache IoTDB
  • 推荐一个学习和了解数据库知识的网站

    最近发现一个有趣的网站,是专门收集世界上所有的数据库信息的网站,类似于维基百科性质的,名字也很有趣叫做Database of Databases,翻译成中文也就...

    哒呵呵

扫码关注云+社区

领取腾讯云代金券