MySQL 高可用和分布式数据库(训练营第六课)

发布于: 2020 年 07 月 15 日

MySQL 高可用

MySQL 主从复制

  • 通过重新执行 binlog 来从 主服务器 复制到 从服务器

  • 从服务器 可以有多台,一主多从

  • 主服务器只用于写操作,从服务器用于读操作

  • 适用于 读多写少 的业务

  • 专门的 从服务器 用于报表、数据分析等读服务重的操作 - 专机专用

  • 读数据的高可用、便于冷备、专机专用、负载分摊

MySQL 主主复制

  • 主服务器 的 高可用

  • 两个数据库 不能 同时并发写入,一个时间只能有一台服务器用于写入

  • 写并发和存储能力并没有增加

  • 任何一台服务器的数据 都是最终一致的

  • 出现服务器失效时,会有一定的数据丢失(未同步的数据)

  • 更新表结构会导致巨大的同步延迟

  • MySQL 的表存储能力一般在 千万数据集

失效迁移

数据分片

  • 硬编码实现数据分片

  • 映射表外部存储 - 实际不多见

分布式数据库中间件

  • Mycat 、Cobar

带中间件数据库如何扩容

  • 提前拆分数据库为多个分片,并分布到集群中

数据库部署方案

  • 主从复制

  • 先 业务分库

  • 再 数据分片

CAP 原理

在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。

  • C(一致性):对某个指定的客户端来说,读操作保证能够返回最新的写操作结果

  • A(可用性):非故障节点将在合理的时间内返回合理的响应(不是错误或超时)

  • P(分区容错):当网络分区发生时,系统将继续正常运作

 

对于分布式系统,网络失效一定会发生,所以分区耐受性是必须要保证的,那么可用性和一致性就不能同时满足;即:

  • 满足 P 的前提下,那么 C 和 A 无法同时满足。

设计妥协

系统设计,通常是 CAP 妥协的结果,很少有 只要一致性不要可用性,或者只要可用性不要一致性

通常是 C 和 A 根据系统的需要作出一定的妥协。

最终一致性

  • 客户端冲突解决 - 购物车合并

  • 投票解决冲突 - Cassandra

  • 写操作 - 等待至少两个节点更新成功

  • 读操作 - 至少两个节点返回,然后取最新的版本

分布式数据库

Cassandra 架构

HBASE 架构

  • HFile 存储在 Hadoop 上面,由 Hadoop 来确保可用性

LogStructed Merge Tree

Doris - 海量 KV Engine

ZooKeeper

分布式系统脑裂

分布式一致性算法 Paxos

ZooKeeper架构

  • 通常采用 奇数台 Node

  • 采用树状记录结构

常见使用场景

  • 配置管理 - 保证一致性

  • 选 Master - 简单、高效

  • 集群管理(负载均衡)

  • Watch Nodes: getChildren(/nodes, true)

  • Ephemeral Node: /nodes/node-${i}

用户头像

看山是山

关注

还未添加个人签名 2018.11.16 加入

还未添加个人简介

评论

发布
暂无评论
MySQL 高可用和分布式数据库(训练营第六课)