学习总结 - 架构师训练营 - 第六周

发布于: 21 小时前
  • 数据分片

数据按照规则存储到不同的服务器。写性能提升

硬分片:例如程序里进行奇偶分片

映射表:外部映射表控制分片规则

挑战:

需要额外的代码,逻辑变复杂;

无多分片的联合查询;

无数据库事务;

根据数据的增长添加服务器,分片规则及数据的迁移

  • CAP原理:

C一致性:返回最新数据或错误,不返回过期数据

A可用性:保证返回数据(不保证最新),不返回错误。

P分区耐受性:部分节点失效,不影响整体系统。

实际环境中,分区耐受性是必须要保证的。在分布式系统中,在必须满足分区耐受性的前提下,可用性和一致性无法同时满足。

实际中的选择:变更逐步扩散,保持最终一致性。

写冲突:时间戳,用最后写入的覆盖之前的

客户端读冲突:读取多处 - 合并结果;投票解决冲突。

  • HBase:HMaster - HRegionServer - HRegion - HFile

  • ACID:放弃可用性。错误就等待

  • BASE:放弃一致性,保证最终一致

基本可用(Basically Available):系统能够基本运行、一直提供服务。

软状态(Soft-state):系统不要求一直保持强一致状态。

最终一致性(Eventual consistency):系统需要在某一时刻后达到一致性要求。

  • 分布式一致性算法:Paxos

Proposer:提案发起者

Acceptor:参与决策者

Learner:接受决策者

每个副本同时具有Proposer、Acceptor、Learner三种角色

  • 角色 - 条件 - 动作

Proposer - - prepare请求( 发送Proposal ID)

Acceptor - 不违反已有的承诺 - promise回应(“两个承诺:最小Proposal ID,一个应答:返回已接受的Accept的最大Proposal ID”)

Proposer - 大多数promise应答 - propose请求(Proposal ID + Value :返回的Accept的value,无则自己指定)

Acceptor - 不违反已有的承诺 - Accept处理(接受Proposal ID和value)

Proposer - 大多数Accept应答 - 发送决议给所有Learner

  • Zookeeper zab协议:

Leader + follower

Leader写,同步到follower

Leader选举

读性能好,写性能差

用户头像

走过路过飞过

关注

还未添加个人签名 2020.04.13 加入

还未添加个人简介

评论

发布
暂无评论
学习总结 - 架构师训练营 - 第六周