架构师速成8.3-可用性之分库分表

有状态分布式,涉及的知识就比较多了,不过我们可以拿几个现实的例子由浅入深的来理解。

数据库的分库分表

  1. 假设你是一个开发负责人,开始使用单机的数据库,突然一天数据库硬盘挂掉了。你没有做备份,然后就没有然后了。
  2. 进入第2个公司,你意识到备份的重要性,每天定时备份到另一台机器,突然有一天,数据库硬盘挂掉了。你心想幸好我有备份,然后巴拉巴拉的恢复起来,用了2个小时。老板说不错,但是—-我们因为宕机造成大量用户流失,信誉下降,然后就又没有然后了。上面说的就是单点的问题。
  3. 进入第3个公司,你觉得单点很可怕,所以主备做起来,数据自动同步到备库,做到随时准备切换。突然有一天,主数据库硬盘挂掉了,你从容的修改数据库连接指向备库,重启系统恢复了,只用了5分钟。此时掌声一片,你沉浸在无比的欢乐中,老板说不错,但是—就在这5分钟我们丢了一个上亿的单子。我擦,你不是故意的吧!(其实这有可能是真实的片段,我们创业时,就30分钟断网,结果正好在举行一个大型的营销策划,不说了,我擦一会眼泪),然后就又没有然后了。其实当你用上主备时,说明数据库已经有状态了,必须要区分谁是主,谁是备。
  4. 进入第4个公司,你不但做了主备,还做了高可用,通过HA实现了瞬时切换。突然有一天,主数据库硬盘挂掉了,你从容的端起了你的屌丝杯,世界清静了。老板说不错,小子我看好你。从此你走向人生巅峰,出任CTO,迎娶白富美。但是没过多久问题来了,随着用户不断的增加,你的数据库摇摇欲坠,不时就抽疯。老板说搞定他,不然我就搞定你。
  5. 咋办,分库分表啊!如何分,这就涉及到更多的规则了,比如按照用户id是最常见的做法。此时你不但需要管主备而且还需要在程序中确定如何路由,结果集合并,如果再有机器增加,还要涉及数据迁移,另外还要防止出现重复id的脏数据,需要全局唯一主键,等等。亚美蝶!知道有状态的痛苦了吧。这也是为什么有些同学转投nosql的存储的很大原因,nosql替你屏蔽了这些规则,他在内部实现了路由、分库、合并等等。
  6. 提到这里不得不提一下淘宝的牛逼产品–drds(沈公子是不是应该给些广告费啊)。
    • 分布式SQL引擎

      • 将数据按照条件分散到多个数据节点(分库分表),对于数据操作sql进行分布式优化,获得最佳执行效率
    • 自主运维
      • DRDS的用户运维平台提供DRDS接入、分布式DDL、拆分信息维护、平滑扩缩容、分布式DML、监控等常用功能,让运维工作变得更简单
    • 小表复制
      • 对于配置表,常量表等不经常变化的表进行多节点对等同步,加速该类表与其他拆分表做关联查询的速度
    • 分布式全局唯一id
      • 提供全局唯一数字id服务,帮助您在分布式环境下,继续保持类似唯一键、主键等数据的全局(所有节点)唯一性
  1. 看到了吧,这就是有状态带来的痛苦。为了把有状态变为无状态有时候你需要做大量的工作。

有关分库分表的关键点和难点,我新一章统一讲解。

时间: 2024-11-24 11:33:51

架构师速成8.3-可用性之分库分表的相关文章

水平分库分表的关键步骤和技术难点

在之前的文章中,我介绍了分库分表的几种表现形式和玩法,也重点介绍了垂直分库所带来的问题和解决方法.本篇中,我们将继续聊聊水平分库分表的一些技巧. 分片技术的由来 关系型数据库本身比较容易成为系统性能瓶颈,单机存储容量.连接数.处理能力等都很有限,数据库本身的"有状态性"导致了它并不像Web和应用服务器那么容易扩展.在互联网行业海量数据和高并发访问的考验下,聪明的技术人员提出了分库分表技术(有些地方也称为Sharding.分片).同时,流行的分布式系统中间件(例如MongoDB.Elas

分库分表的几种常见玩法及如何解决跨库查询等问题

在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片"."Sharding"-这样的关键词.让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战.让人感到担忧的是,他们系统真的就需要"分库分表"了吗?"分库分表"有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议. 垂直分表 垂直分表在日常开

架构师速成-目录

天地会总舵,陈近南给了韦小宝一本武功秘笈,韦小宝说:"嗯?这么大一本我看要练个把月啊!" 陈近南说:"这本只不过是绝世武功的目录,那边才是绝世武功的秘笈!" 这就是架构速成的秘笈目录 架构师速成1-前言 架构师速成2-概述 架构师速成2.1-论成功 架构师速成2.2-论成功 架构师速成3-开发者境界 架构师速成4-幼儿园 架构师速成4.1-幼儿园要学会如何学习 架构师速成4.2-幼儿园要学会如何学习 架构师速成4.3-幼儿园要学会查找资料 架构师速成5-小学 架构师

架构师速成2-概述

成为一名合格的架构师,需要经历菜鸟.码农.资深码农.项目经理.技术经理.架构师等一系列的过程.为了让大家通俗易懂,我把整个过程按照大家熟知的上学的顺序排了一下,从幼儿园-小学-中学--一直到博士,至于博士后需要大家自己去实践和想象了.每个过程我都会进行统一的描述: 阶段:例如 幼儿园 需要做的事情:例如 学会一门编程语言 完成任务耗时:例如 2-5个月 升级标准:例如:能写出简单的计算器,接受用户输入的+-x/运算 风险:例如 有人打断 当然在正式开始之前,我还是要提示一下相关的风险: 任何行业

架构师速成8.4-分库分表的关键点

我们还是由浅入深(这个词我喜欢,你呢?)的讨论一下,分库分表的关键点(本故事纯属虚构,仅为搞笑): 当你的系统很小的时候,只有一个数据库,每个表的主键都是自增的,你都不去关心主键变成了多少,反正db保证自增,小日子过的很是惬意.但惬意的日子总是短暂的,你因为DB宕机被老板fire 3次(见上一个故事). 进入第4个公司的时候,你发粪涂墙,将集群改成主备HA,结果顺利出任CTO,迎娶白富美,走向了人生巅峰.当然这中间也出过一些小插曲,比如:张三注册时,刚点击完注册,DB主机宕机了.张三发现刚注册的

水平分库分表的关键问题及解决思路

分片技术的由来 关系型数据库本身比较容易成为系统性能瓶颈,单机存储容量.连接数.处理能力等都很有限,数据库本身的"有状态性"导致了它并不像Web和应用服务器那么容易扩展.在互联网行业海量数据和高并发访问的考验下,聪明的技术人员提出了分库分表技术(有些地方也称为Sharding.分片).同时,流行的分布式系统中间件(例如MongoDB.ElasticSearch等)均自身友好支持Sharding,其原理和思想都是大同小异的. 分布式全局唯一ID 在很多中小项目中,我们往往直接使用数据库自

透明的分库分表方案

问题提出 随着应用规模的不断扩大,单机数据库就慢慢无法满足应用的需要了,这主要表现在如下方面: 存量数据越来越大,查询速度越来越慢 访问并发越来越大,磁盘IO.网络IO.CPU都慢慢成为瓶颈 事务数越来越多,事务冲突越来越严重,导致TPS越来越少 这个时候,有的人采用了换商用数据库的方案比如Oracle,然后用Oracle的RAC方式进行水平扩展.但是带来的缺点也比较明显,第一是成本太高,一般人吃不消:第二,管理复杂度较单节点有非常大的提升,风险及管理成本也相应增加:第三,对人员的水平要求更高,

【转】微服务MySQL分库分表数据到MongoDB同步方案

需求背景 近年来,微服务概念持续火热,网络上针对微服务和单体架构的讨论也是越来越多,面对日益增长的业务需求是,很多公司做技术架构升级时优先选用微服务方式.我所在公司也是选的这个方向来升级技术架构,以支撑更大访问量和更方便的业务扩展. 发现问题 微服务拆分主要分两种方式:拆分业务系统不拆分数据库,拆分业务系统拆分库.如果数据规模小的话大可不必拆分数据库,因为拆分数据看必将面对多维度数据查询,跨进程之间的事务等问题.而我所在公司随着业务发展单数据库实例已经不能满足业务需要,所以选择了拆分业务系统同时

当当开源sharding-jdbc,轻量级数据库分库分表中间件

近期,当当开源了数据库分库分表中间件sharding-jdbc. Sharding-JDBC是当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,实现透明化数据库分库分表访问.Sharding-JDBC是继dubbox和elastic-job之后,ddframe系列开源的第3个项目. Sharding-JDBC直接封装JDBC协议,可以理解为增强版的JDBC驱动,旧代码迁移成本几乎为零. Sharding-JDBC定位为轻量级java框架,使用客户端直连数