架构师训练营 - 第⑥周总结

分布式数据库

• 主从复制&一主多从复制（分摊负载、专机专用、便于冷备、高可用）

• 分离读写，提高读可用性，某从机宕机不影响数据库访问

• 写操作可用性不变，主机宕机只影响写操作

• 主主复制

• 主主复制的两个库不能并发写入，只是提高了数据库写操作的可用性

• 复制只是增加了数据库的读并发能力，没有增加并写能力和存储能力

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

• 数据分片

• 硬编码实现数据分片

• 映射表外部存储

• 挑战

• 大量额外代码，处理逻辑复杂

• 无法执行多分片联合查询，无法使用数据库事物

• 随着数据增长，如何扩展是难题

• 分布式数据库中间件（推荐）

• 数据库部署方案：

• 单一服务与单一数据库

• 主从复制实现伸缩

• 两个服务与两个数据库

• 综合部署（分库、主从、主主、分片）

CAP原理：分布式系统必须满足分区容错性的前提下，一致性和可用性无法同时满足

• 一致性：每次读取到的都是最新数据或者返回失败，而不是过期数据

• 可用性：每次请求都应该得到相应，而不是返回错误或失去相应，但响应的数据不保证是最新的

• 分区容错性：部分服务器节点间消息丢失或者超时，系统依然可操作

• 当节点时效时，我们如果要保持一致性，就需要取消操作导致可用性降低，如果要保持可用性继续操作，一致性就不能保障

• 对一个分布式系统而言，节点超时或失效必然存在，这时就需要在可用性和一致性上做出选择

• 可用性相比一致性更重要，系统优先保障可用性，一致性只保证最终一致性，存在一定延迟

• 最终一致性冲突解决方案：按时间戳最后写入覆盖；客户端解决冲突；投票（Cassandra）

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

BASE

• 基本可用：系统出现故障时允许出现响应延迟或功能上的损失

• 软状态：允许数据在节点间同步出现一定延迟

• 最终一致性：系统所有副本数据在经历一定时间后最终达到一致状态

ZOOKEEPER

• 分布式一致性算法paxos：提案者、投票者、学习者

• zk集群节点单数部署

• 读性能卓越，写性能随着节点数增加性能下降