架构师训练营 Week 06 总结

1分布式数据库

1.1 MySQL复制

1.1.1 主从复制

1.1.2 一主多从复制

优点：

• 分摊负载

• 专机专用

• 便于冷备

• 高可用

1.1.3 主主复制

1.1.4 主主失效恢复

1.1.4.1 主主失效的维护过程

1.1.5 复制注意事项

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

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

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

1.2 数据分片

1.2.1 分片映射方式

1.2.1.1 余数哈希

1.2.1.2 外部储存映射表

1.2.2 数据分片的挑战

• 需要大量的额外代码，因此处理逻辑变得更复杂

• 无法执行分片的联合查询（可以应用层做联合）

• 无法使用数据库的事务

• 随着数据的增长，如何增加更多服务器

1.3 分布式数据库中间件

Mycat（包含Amoeba、Cobar组件）

1.3.1 架构

Amoeba、Cobar架构

Cobar系统组件模型

1.3.2 路由配置

1.3.3 扩容策略

实践中，是预先设定系统的分片数量，每个分片对应一个Schema数据库文件。增加服务器时，从各个服务器中拷贝Schema到新的服务器中。

1.3.4 部署方案

1.3.4.1 单一服务于单一数据库

1.3.4.2 主从复制实现伸缩

1.3.4.3 两个Web服务及两个数据库

1.3.4.4 综合部署

2 CAP原理

2.1 组成元素

• 一致性。每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据。

• 可用性。每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是不保证响应的数据是最新的。

• 分区耐受性。即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。

2.2 CAP原理

• 当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性就得不到保证。

• 对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。

• 当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不能保证这个数据是最新的。

• 所以，关于CAP原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下，可用性的一致性无法同时满足。

2.2.1 数据存储冲突

2.2.2 最终一致性

2.2.3 最终一致写冲突

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

2.2.4 客户端冲突解决

2.2.5 投票解决冲突（Cassandra）

2.2.6 Cassandra的分布式解决方案

2.3 Hbase架构