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

• https://github.com/itisaid/Doris

• A large scale distributed cloud-style KV storage system from Alibaba.

• 海量分布式 K-V 存储系统

ZooKeeper

分布式系统脑裂

分布式一致性算法 Paxos

ZooKeeper架构

• 通常采用 奇数台 Node

• 采用树状记录结构

常见使用场景

• 配置管理 - 保证一致性

• 选 Master - 简单、高效

• 集群管理（负载均衡）

• Watch Nodes: getChildren(/nodes, true)

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