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

• 数据分片

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

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

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

挑战：

需要额外的代码，逻辑变复杂；

无多分片的联合查询；

无数据库事务；

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



• 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选举

读性能好，写性能差