架构师训练营 Week 06 总结

发布于: 2020 年 07 月 14 日

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架构

用户头像

Wancho

关注

还未添加个人签名 2020.02.28 加入

还未添加个人简介

评论 (1 条评论)

发布
用户头像
请添加“极客大学架构师训练营”标签,方便分类
14 小时前
回复
没有更多了
架构师训练营 Week 06 总结