MySQL架构演进:从主从复制到分库分表


MySQL架构演进:从主从复制到分库分表

背景

MySQL架构演进:从主从复制到分库分表


业务飞速发展导致数据规模急速膨胀,单机的数据库已经无法满足互联网业务的发展。

传统的将数据集中存储单一数据结节的方案,在容量、性能、可用性和可维护性方面已经难以满足互联网海量数据的场景。

从容量方面考虑,单机数据库容量有限,难以扩容。

从性能方面来说,由于关系型数据库大多数采用B+树类型索引,在数据量超过一定的阈值后,索引的深度增加导致对磁盘的随机IO次数增加,进而导致性能问题。

从可用性方面来说,服务通常设计成无状态的,这必然导致系统的存储压力都集中在数据库层面,而单一的数据节点,或者简单的主从架构,已经越来越难以承担。

从运维角度来看,当数据都集中在一个节点上时,数据备份和恢复的时间成本也随之数据量上升变得不可控。同时数据丢失导致影响的范围也会被放大。

MySQL架构演进:从主从复制到分库分表


MySQL架构演进:从主从复制到分库分表

主从复制

MySQL架构演进:从主从复制到分库分表


  • 主库将事务操作(除了查询以外的操作)记录到binlog
  • 从库通过relay log同步数据,实现数据的同步
MySQL架构演进:从主从复制到分库分表
binlog日志格式
  • row 记录数据库操作详细记录,包括上线文信息等,文件较大。
  • statement 记录事务相关的SQL文件。
  • mixed 混合式, 基于row和statement两种文件格式。

异步复制

2000年,MySQL3.23.15版本引入复制功能,采用异步复制的方式,当网络或者机器故障,会导致数据不一致。
MySQL架构演进:从主从复制到分库分表

半同步复制

2010年, MySQL 5.5版本引入半同步复制, 半同步复制是指只要一个salve节点返回ack,master节点就可以提交事务了,保证数据库至少有一个节点完成了数据的同步。
MySQL架构演进:从主从复制到分库分表

组复制

2016年,MysQL在5.7.17中引入InnoDB Group Replication,该方案基于paxos协议实现组内复制,保证数据一致性,paxos协议核心在于过半选举。
MySQL架构演进:从主从复制到分库分表

主从复制的问题

  • 主从复制延迟,导致”写完读”数据不一致问题。
    • 从库读取失败,再去主库执行一遍SQL,存在性能问题。
    • 业务层保证系统核心功能可用,将核心功能的CRUD操作都路由到主库,非核心业务功能即使存在短暂数据不一致也影响不大。
  • 路由问题,需要业务层根据SQL路由到不同的数据库,路由到SLAVE节点时,还需要保证系统负载均衡。
    • 业务层通过框架(如sharding-jdbc)或者手动实现,对业务的侵入性较大,已存在的旧系统改造不友好。
    • 通过数据库中间件实现(如mycat、sharding-proxy),需要部署一个中间件(中间件实现SQL标准),规则配置在中间件,执行过程中会多一次网络转发。
  • 不能保证系统高可用
    • 通过一系列高可用的解决方案保证数据库高可用


MySQL架构演进:从主从复制到分库分表

数据库高可用

MySQL架构演进:从主从复制到分库分表


什么是高可用?

高可用意味着,更少的服务不可用的时间,一般用SLA(服务级别协议)衡量。
1年 = 365天 = 8760小时
99 = 8760 * 1% = 8760 * 0.01 = 87.6小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

为什么要做高可用?

通过故障转移,提供failover的能力,加上业务侧连接池的心跳重试,实现断线重连,业务不间断,降低RTO(Recovery Time Objective,复原时间目标)和RPO(Recovery Point Objective,复原点目标)。
  • 容灾恢复:冷备和热备,冷备和热备的区别在于运行期间是否提供服务。
  • 对于主从来说,简单的来说就是Master节点挂了,某一个从节点,自动切换成主。
  • 从集群来看,即便是个别节点挂了,能正常对外提供服务。
常见的策略:
  • 多实例部署
  • 跨机房部署
  • 两地三中心容灾高可用方案等。

手动切换

即如果主节点宕机,手动将某个从节点修改成主节点。
存在的问题:
  • 可能数据不一致
  • 需要人工干预
  • 代码和配置的侵入性,需要配置其他节点,修改应用数据源的配置。

MHA

MHA全称叫做MySQL Master High Availability,是由Facebook工程师Yoshinori Matsunobu开发的一款MySQL高可用框架,基于Perl语言开发,一般能在30秒内实现主从切换,切换时通过SSH复制主节点的日志信息。
MHA负责MySQL主库的高可用,当主库发生故障时,MHA会选择一个数量最接近原主库的候选节点作为新的主节点,并且补齐和之前宕机的Master差异的Binlog。数据补齐后,即将写VIP漂移到新的主库上。具体的架构图如下:
MySQL架构演进:从主从复制到分库分表
优点
  • 可以进行根据具体的故障实现自动检测和故障转移
  • 扩展性好,可以任意的扩展数据节点数量
缺点:
  • 极限情况下,可能会发生脑裂现象,出现多个Master。
  • 需要配置SSH信息。
  • 至少需要三台。

MGR

MGR是数据库支持的,只需要配置插件即可,如果主节点挂掉,将自动选择某个从改为主。无需人工干预,并且基于组复制(paxos算法),保证数据一致性。
MySQL架构演进:从主从复制到分库分表
MGR的特点
  • 高一致性,基于分布式Paxos协议实现复制,保证数据一致性。
  • 高容错性,自动检测机制,只要大多数节点都宕机的情况下,数据库可以继续工作,内置防脑裂保护机制。
  • 高可扩展性,加入新节点后,自动实现增量同步,直到与其他节点数据一致。
  • 高灵活性,提供了单主和多主模式,单主模式支持主节点宕机,自动选主,多主模式支持多节点写入。
MySQL InnoDb Cluster,一个完整的数据库高可用解决框架,由多个组件组成
  • MySQL Group Replication,提供DB的扩展,故障迁移
  • MySQL Router,轻量级中间件,提供应用程序连接目标的故障转移。
  • MySQL shell,新的MySQL客户端,多种接口模式,可以设置群组复制和Router。
MySQL架构演进:从主从复制到分库分表

Orchestrator

一款MySQL高可用和复制拓扑管理工具,支持复制拓扑结构的调整,自动故障迁移和手动切换的功能等,直接拖拽UI,就可以实现主从切换。
微信搜索公众号:Linux技术迷,回复:linux 领取资料 。

分库分表

分库分表通常是指垂直分库和水平分表,对于垂直分表其实就是将宽表拆分成小表,没有太多的技术挑战,这里侧重讲讲垂直分库和水平分表。

垂直分库

垂直分库是指将数据库进行纵向切分,通常按照业务的维度进行划分。
如典型的微服务的架构,将系统按照业务维度垂直拆分,划分成多个服务。如一个电商网站可以拆分成:订单、商品、会员、支付等服务。
MySQL架构演进:从主从复制到分库分表
垂直分库后业务更加单纯,职责单一,同时可以解决部分数据库容量问题,但是同时也引入了新的技术复杂度,如下:
  • 分布式事务,跨数据库的事务操作需要分布式事务支持,否则系统将会面临数据不一致的问题。
    • 方案一,采用XA事务,XA事务是数据库本身支持规范,具备强一致性的特征,但是性能比较差,对于追求高性能的场景不适合使用XA事务。
    • 方案二,采用柔性事务,柔性事务是指,数据库保证局部事务,全局事务实现由业务层实现(如通过调度补偿,重试补偿,人工介入等),柔性事务常见的解决方案有:TCC、利用消息队列实现事务。
  • join问题,分库后,表分散到不同的数据库,无法直接使用SQL进行JOIN操作,需要业务层自己实现聚合操作,增加了开发成本。

水平分表

水平分表是指,将表按照某种规则分成多张表,拆分后的表结构和拆分前完全一致,但是数据分散到多张表中,也可以成为数据分片。
MySQL架构演进:从主从复制到分库分表
通过水平分表,解决了单表的容量和性能问题。但同时,水平分表后,引入了新的技术复杂度,主要有以下几点:
  • 路由问题,当业务层通过SQL对数据库进行DML操作时,到底该查询那张表呢?
    • 方案一:范围路由。根据表中某一列(分片键)的取值范围进行分表,如根据创建时间将主表分成多张表,每个月的数据单独存储在一个表中。范围路由可能出现数据分配不均匀的现象,但是表数量易于扩展。
    • 方案二:哈希路由。根据表中某一列与分片数量取模运算(field_value % table_num)。hash路由和范围路由相反。表数量扩展时都会导致数据重新分布,但是数据分布较为均匀。
  • join问题,由于分表后,数据分散到多个表中,JOIN的条件语句中如果没有分片键,那么需要将全部的分片表都JOIN一遍,这种操作会存在性能问题。
  • count问题,分表后,如果需要统计表记录总和,需要遍历所有的表,然后再将结果进行汇总,可以通过一张单独的汇总表来解决,但这种解决方案需要每次insert或者delete的时候就需要更新汇总表,如果有一次没有更新,就会导致数据不一致。
  • order by问题,分表后,如果需要进行排序,需要遍历所有的表,然后在代码层进行重新排序,这个操作一看就会存在性能问题。

分库分表解决方案

  • 业务代码层解决,可以通过SQL手动处理路由,但是和业务的耦合很严重,不易于维护。通常采用集成jar包的方式进行解决,如集成成熟的开源项目:sharding-jdbc。
  • 数据库中间件,数据库中间件实现了对应数据库的SQL标准,路由规则配置在数据库中间件,业务代码操作数据库中间件和直接操作数据库没有任何区别。


MySQL架构演进:从主从复制到分库分表

总结

MySQL架构演进:从主从复制到分库分表


从单节点数据库到主从复制,再到数据库高可用,再到分库分表,很好的解决了数据的性能、容量、高可用、运维性等问题,但是会带来分布式事务、复杂SQL难以操作、SQL路由等问题。
架构设计应该遵循:”简单性”、”合适性”、”演化性”的原则,符合当前的业务发展,所以系统设计没有必要一上来就考虑分库分表,而应该是数据量达到一定的量,出现性能瓶颈的时候再对系统进行改造和优化。

如喜欢本文,请点击右上角,把文章分享到朋友圈

因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享

    作者:小泥洼

    来源:juejin.cn/post/6932298813453369358

    版权申明:内容来源网络,仅供分享学习,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!

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

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

    (0)
    上一篇 10月 15, 2022 6:17 上午
    下一篇 10月 20, 2022 12:05 上午

    相关推荐

    • 【收藏】19张最全的架构师技术栈图谱

      嗨喽,各位新来的小伙伴们,你们好!由于公众号做了改版,为了保证公众号的资源推送,能够第一时间及时送达,大家记得将小编的公众号 加星标置顶 ,在此真诚的感谢! 今…

      6月 18, 2022
      200
    • 使用uuid做MySQL主键,被老板,爆怼一顿!

      作者:Java码农链接:https://www.jianshu.com/p/512f626b2a8d 前言:在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续…

      11月 13, 2022
      130
    • 架构师带你彻底搞懂Nginx的五大应用场景

      HTTP服务器 Nginx本身也是一个静态资源的服务器,当只有静态资源的时候,就可以使用Nginx来做服务器,如果一个网站只是静态页面的话,那么就可以通过这种方式来实现部署。 1、…

      7月 11, 2022
      170
    • 架构师聊聊分布式定时任务框架选型

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

      8月 7, 2022
      230
    • 测试架构师必读:编码规范、开发技巧、架构画图

      本文转载至:测试开发技术订阅号 作为一名测试开发或者测试工程师来说,掌握程序设计、编程技能已经是基本要求了,但如果你想进阶更高的层次,或者你想成为一名合格的测试架构师,除了要掌握如…

      6月 20, 2022
      220
    • 面试官让我手写一个RPC框架 ,so easy !

      作者:Java码农链接:https://www.jianshu.com/p/08108654b083 如今,分布式系统大行其道,RPC 有着举足轻重的地位。Dubbo、Thrift…

      9月 9, 2022
      330
    • 架构师必须清楚的支付系统:对账系统详解

      在支付系统中,资金对账在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生…

      7月 3, 2022
      220
    • 一张图看懂微服务架构路线

      我为什么选择微服务架构? 众所周知,单体应用程序,由于其种种不足,几乎不支持敏捷方法。如果你想为一个大型或复杂的业务创建一个软件项目,最好从微服务架构开始。 微服务架构是一种灵活的…

      6月 29, 2022
      180
    • 架构师玩转秒杀系统设计

      业务场景分析 业务场景:商品秒杀、商品抢购、群红包、抢优惠券、抽奖、买火车票 业务特点:瞬时售空、瞬时并发高、持续时间短、一般是商品定时上架 技术特点:读多写少、高并发、资源冲突 …

      7月 22, 2022
      200
    • 美团外卖即时物流的分布式系统架构设计

      背景 美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点: 即时物流业务对故障…

      7月 12, 2022
      210

    发表回复

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