首页 > 极客资料 博客日记

数据裂变,数据库高可用架构设计实践

2024-08-15 08:30:03极客资料围观22

这篇文章介绍了数据裂变,数据库高可用架构设计实践,分享给大家做个参考,收藏极客之家收获更多编程知识

相关文章

数据库系列:MySQL慢查询分析和性能优化
数据库系列:MySQL索引优化总结(综合版)
数据库系列:高并发下的数据字段变更
数据库系列:覆盖索引和规避回表
数据库系列:数据库高可用及无损扩容
数据库系列:使用高区分度索引列提升性能
数据库系列:前缀索引和索引长度的取舍
数据库系列:MySQL引擎MyISAM和InnoDB的比较
数据库系列:InnoDB下实现高并发控制
数据库系列:事务的4种隔离级别
数据库系列:RR和RC下,快照读的区别
数据库系列:MySQL InnoDB锁机制介绍
数据库系列:MySQL不同操作分别用什么锁?
数据库系列:业内主流MySQL数据中间件梳理
数据库系列:巨量数据表的分页性能问题
数据库系列: 主流分库分表中间件介绍(图文总结)

★ 针对常见的互联网业务场景进行数据库架构设计总结

1 先导

我们的系统会随着业务的膨胀而越发的复杂,数据基数也会越变得越来越大。
如何在数据变为巨量数据之后,依然保持强有力的稳定性和高效的性能,是系统架构的一个重要的目标,下面我们按照数据架构的演进来阐述变化过程。

2 演进

2.1 单体

一般是产品设计之初,或者试运行阶段。

image

最常见的架构设计如上:

  1. Service:服务层,对调用者提供优质的Rset或者RPC接口,同时能获取数据库数据
  2. DB:数据层,一般是单库,负责数据存储

2.2 冷热分离架构

历史数据访问频率比较低,可以放在独立的表或者库中。比如你的去年之前的朋友圈,当有需要的时候才回去翻阅。
但是最近一周内的朋友圈信息(无论是你的还是你朋友发的图文,都是热数据),为了性能,为了你的活跃数据的表更轻便一点,必然要做隔离。

image
架构如上:

  1. Service:服务层,对调用者提供良好的Rset或者RPC接口,同时能获取数据库数据
  2. DB-Cool:冷数据库,一般存放历史比较久远的数据,数据量庞大,能够忍受加载效率慢
  3. DB-Hot:热数据库,一般存近期活跃数据,数据量不会很庞大,加载效率高

2.3 读写分离架构

多读少些的场景已经形成了,大量的读操作影响到写数据的性能和稳定性了,为了解决【数据库读写高并发】 的问题而设计。
当然可引入缓存、消息队列等中间件支撑,咱们这边不提。

image

如上,这是最常见的1主N从,读写分离的数据库模式:

  1. Service:服务层,对调用者提供良好的Rset或者RPC接口,同时能获取数据库数据
  2. DB-M(master):主库,提供数据库写服务
  3. DB-R(replicate):从库,提供数据库读服务

它有如下特点:

  1. 1主n从,线性提升读的性能,当然n不是越多越好,也会有复制压力
  2. 主从之间通过binlog来进行写操作的replay,实现数据复制
  3. 主从之前的数据结构和数据结果完全一直,即使会有同步延迟,最终还是要一致的
  4. 注意写依然是单点,那是因为互联网业务中,高频写的热数据占比一般都是很低的

2.4 数据分片架构

典型sharding(水平拆分)方案。
水平拆分又分为库内分表和分库分表,来解决单表中数据量增长出现的压力,这些数据库中的表结构完全相同,我们这边按照分库分表来介绍。
image
架构如上:

  1. Service:服务层,对调用者提供良好的Rset或者RPC接口,同时能获取数据库数据
  2. DB-0、DB-2:数据按照分片进行还分,这边的例子每1KW存一个分片

水平分区的数据可以按照这5种策略隔离:

2.4.1 Hash(哈希)

这种策略是通过对表的一个或多个列的Hash Key进行计算,最后通过这个Hash码不同数值对应的数据区域进行分区。例如我们可以建立一个对表的日期的年份进行分区的策略,这样每个年份都会被聚集在一个区间。

1 PARTITION BY HASH(YEAR(createtime))
2 PARTITIONS 10

image

2.4.2 Range(范围)

这种策略是将数据划分不同范围。例如我们可以将一个千万级别的表通过id划分成4个分区,每个分区大约250W的数据,超过750W后的数据统一放在第4个分区。

PARTITION BY RANGE(id) (
PARTITIONP0 VALUES LESS THAN(2500001),
PARTITIONP1 VALUES LESS THAN(5000001),
PARTITIONp2 VALUES LESS THAN(7500001),
PARTITIONp3 VALUES LESS THAN MAXVALUE
)

image

还有 Key(键值) 、List(预定义列表)、Composite(复合模式) ,请翻开我的这两篇文章:
MySQL全面瓦解28:分库分表
MySQL全面瓦解29:分库分表之Partition功能详解

2.4.3 解决什么问题?

  1. 数据库/数据表瘦身,提升读写性能
  2. 缩小故障影响范围(故障爆炸半径)

3 总结

  1. 产品发展初期,使用单库模式
  2. 部分数据写固化,读频率降低,使用冷热隔离架构
  3. 业务量扩大,多读少些占比重,使用读写分离的主从架构
  4. 数据基量膨胀,让检索不堪重负,使用分片(分库分表)架构
  5. 呀,不写了,去跑步咯

版权声明:本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!

标签:

相关文章

本站推荐

标签云