第 6 周学习心得

MySQL复制



MySQL主从复制

读写分离，应用在有大量读操作场景，可以一主多从：分摊负载、专机专用、高可用

MySQL主主复制

解决当主数据库失效不可用的问题：当发现失效时，进行失效转移，将写操作发送到第二个服务器，开始重建失效服务器数据，当失效机器完全恢复时，继续保持主服务器间复制机制。

• 主主复制的两个数据库不能并发写入

• 复制只是增加数据的读并发处理能力，并不能解决写并发的处理和存储能力

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



数据分片

解决写并发的存储能力

硬编码实现数据分片

根据key映射服务器编号

根据key通过外部存储来映射服务器编号

挑战：

• 需要额外代码

• 无法执行多分片联合查询

• 无法使用数据库事务

• 增加更多服务器改动大

采用数据库中间件

• Amoeba

• Cobar

SQL解析 -> SQL路由 -> SQL执行 -> 后端通讯模块 -> 数据库

集群伸缩

同一张表进行分片，分成多个schema，以schema为单位计算在哪个节点。当要扩展节点时，schema不用划分，只需要重新安排schema归属的节点，进行schema迁移



CAP

CAP原理

• Consistency

• Availability

• Partition tolarence

CAP P是前提集成，必须保证。C和A不能同时满足

最终一致性

• 简单冲突处理策略：根据时间戳，最后写入覆盖

• 客户端冲突解决

• 投票解决冲突（Cassandra):客户端连接到任意一节点，按照投票一致性写入一个节点，该节点计算要存储的分区范围，查询发送给存有数据的其他节点进行投票，当过半数通过时，数据写入更新所有存有数据的节点。

HBase结构

LogStructed Merge Tree

（待补充）

ACID与BASE

原子性、隔离性、持久性、一致性

BA：基本可用

S：弱状态

E：最终一致



Zookeeper

分布式一致性算法Paxos

(待补充)

Zookeeper架构

(待补充)



Doris - 海量KV Engine

(待补充)