架构师 Week6 学习总结

CAP原理

当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是这样数据的一致性就得不到保证了。因为对于一个分布式系统而言，网络失效故障是一定会发生的，那么我们只能选中AP和CP了。即：当网络故障时，如果选择了一致性，那么系统就可能返回错误码或者直接超市，即系统不可用。如果选择了可用性，那么最终用户读取的数据是一定不一致的。

1、CAP原理与数据一致性冲突：

1）、最终一致性：

2）、最终一致写冲突：根据时间戳，最后写入覆盖

3）、客户端冲突解决

4）、投票解决冲突

5）、Cassandra分布式解决方案

6）、Hbase解决方案





数据库的ACID和BASE：

ACID：

• 原子性（Atomicity）:事务要么全部完成，要么全部取消。如果事物崩溃，进行事务回滚。

• 隔离性（Isolation）：如果2个事务T1和T2同时运行，则需要T1和T2的最终结果是一致的，这依赖于锁的实现。

• 持久性（Durability）：一旦事务提交，不管发生什么，崩溃或者出错，数据要保存在数据库中。

• 一致性（Consistency）：只有合法的数据（依照关系约束和函数约束）才能写入数据库。

BASE:

• 基本可用系统（BA）在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。

• Soft state软状态，指允许系统中的二数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本直接进行数据同步的过程存在延时。

• Eventually consistent，指系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。



Zookeeper相关知识

在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据毁坏，称作分布式系统脑裂。

主要算法：Paxos算法

三个角色：Proposer、Acceptor、Learner

第一阶段：Prepare阶段，Proposer向ACCEPTORS发出Prepare请求，Acceptor针对收到的Prepare请求就行Promise承诺。

第二阶段：Accept阶段，Proposer收到多数Acceptor承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。

第三阶段：Learn阶段，Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。

Proposer生成全局唯一且递增的ProposalID，向所有Acdeptors发生Prepare请求，这里无需携带提案内容，只携带Proposal ID即可。

Acceptors收到Prepare和Propose请求后

1、不再接受Proposal ID小于等于当前请求的Prepare请求。

2、不再接受Proposal ID小于当前请求的Prepose请求。



架构图：

主要协议，ZAB协议：



请求先经过Follower，然后传入Leader进行决策。

目录结构：

相关API(JAVA)：

选master，python实现：

handle = zookeeper.init("localhost:2181",my_connection_watcher,10000,0)
(data,stat) = zookeeper.get(handle,"app/leader",true)
if(stat == None):
  path = zookeeper.create(handle,"app/leader",hostname:info,[ZOO_OPEN_ACL_UNSAFE],zookeeper.EPHEMERAL)
  if(path == None):
    data,stat = zookeeper.get(handle,"app/leader",True)
  else:
    pass
else:
  pass