WEEK6- 学习心得



CAP 原理

C 一致性 ：返回的数据是对的，要么不返回；

A 可用性：每次访问都应该返回一个响应；

P 分区耐受性：要么取消操作，这样数据就是一致的，但是系统却不可用，要么我们继续写入数据，但是数据一致性就得不到保证。

在数据可用性和一致性上必须二选一；

要么CP 要么 AP



一个分布式系统是无法同时满足 CAP



架构师需要知道部分需求是无法同时满足，任何一个系统都存在这样的问题。



CAP原理和数据一致性冲突的实例：

解决一致性冲突：

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

（2）客户端解决冲突，在客户端进行合并；

（3）投票解决冲突；



ACID 和 BASE



ACID 要么全部完成，要么全部不完成。

原子性

隔离性

持久性

一致性



MySQL 分区是运维的手段；

MYSQL的分库分表分片是应用程序的手段；

通常需要提前半年需要开始准备分库分表。



脑裂问题

需要有个控制中心来做仲裁，控制中心本身也要再准备2台；

比如：zookeeper



PAXOS 分布式一致性算法。（高频，重要）

算法有三个角色：

• proposer

• acceptor

• learner

每台服务器都有这3个角色



zookeeper 对PAXOS 算法进行了简化，ZAB协议。



流程：

request->LEADER ->follower

request->propose->ack->commit;



zookeeper 一致性是优先得到保证；

leader会进行选举；



zookeeper service

所有的service节点数据都是一致的，所以都可以读。

写入某个service的节点，会触发propose。



解决场景：

如果发生了冲突；

如何对锁进行进分配。

ZOOKEEPER 来决定 谁是主节点，谁是备节点。



关注点：如果ZOOKEEPER的服务器宕机超过半数，导致无法投票，也会导致不可用。



ZOOKEEPER 的树状记录结构。

ZOOKEEPER 的API



应用程序和ZOOKEEPER 之间是长连接。

• 两边是双向通信；

• 双向通知；



设置： set

获取： get

监视：watch



如果集群数据发生变化，zookeeper会通知；不需要重启服务



ZOOKEEPER 就是为了做分布式一致性。

阿里是通过数据库来做的，但是数据库的吞吐能力会有限。



ZOOKEEPER 满足集群管理（负载均衡和失效转移）



ZOOKEEPER 的性能：

节点越多；需要投票的服务器就越多；