zookeeper

                      Zookeeper

       理解并发

         1、多线程的引入。

              深入理解计算机概念:一书上说 如果逻辑控制流时间上重叠，那就是并发。

         2、分布式一致性问题

            分布式对数据的复制一般来自两个原因

            *为了增加系统的可用性，防止系统的单点故障引起的不可用。

            *提高系统的整体性能，通过负载均衡技术，能够将分布在不同地方的数据副本提供给用户服务  

            分布式一致性的级别

               *强一致性：系统写什么，读的就是什么

               *弱一致性：不确定什么时间是一致的

                  会话一致性：同一个会话是一致的。

                  用户一致性：同一个用户是一致的。

               *最终一致性

                 它是弱一致性的一种。

             第一章

         分布式架构

       从集中式到分布式的演变

        1 培养人才成本比较高

        2 售价高

        3 单点故障

       分布式特点：

       分布式系统的特点：将不同的软件或者硬件分布在不同的网络计算机上然后通过消息传递和协调

       分布性

       对等性

       并发性

       缺乏全局性时钟

       故障总会发生

       分布式环境的各种问题

       通信异常

       网络分区

       三态：成功  失败   超时

       节点故障

       从acid 到cap/base

       事务是由一系列对数据进行操作和访问与更新的所组成的一个程序执行的逻辑单元

       事务有四个特点

       原子性

       全部成功

       全部失败

       一致性

       隔离性

       4个隔离级别

       未授权读也叫读未提交 可以脏读

       授权读也叫读已提交

       可重复读 幻读

       串行化 不能并行执行

  

          Cap 理论  一致性  可用性 以及分区容错性 只能满足两个需求

          BASE理论 

基本可用 

响应时间的缺失

功能上的缺失

软状态

最终一致

因果一致性

读己之所性

会话一致性

单调读一致性

单调写一致性

第二章

一致性协议

2pc 和3pc

两段式提交 和三段式提交

两段式提交

 阶段一 提交阶段请求 投票阶段

 1 事务询问

   协调这向所有参与者询问是否提交事务提交操作并开始等待参与者响应。

2 各参与者节点执行事务操作，并将undo和redo 信息记入事务日志中。

3各参与向协调者反馈事务询问的响应
            成功执行了事务发出yes 或者no

阶段二 执行事务提交

执行事务提交

1 发送提交请求

协调者向所有参与者发出commit 请求

           2 事务提交

             参与者在接收到commit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务在执行期间所占的资源。

           3 反馈事务提交结果

             参与者在完成事务提交之后,向协调者发送ack 消息。

          4完成事务

              协调者接收到所有参与者的Ack，完成事务。

         中断事务

           假如一半以上的协调者发出no 或者等待超时，就会发出中断请求。

1. 发送回滚请求

协调者向参与者发送回滚请求

1. 事务回滚‘

参与者接收到回滚请求后，会利用第一阶段记录的undo 信息执行回滚操作，并在完成事务回滚之后释放所占事务资源。

1. 反馈事务回滚结果

参与者在完成事务回滚之后，向协调者发送ack 信息

1. 中断事务

协调者在参与者反馈ack 消息之后，中断事务。

二阶段提交是最终一致性算法。

二阶段提交的优缺点:

 优点：原理简单 实现方便

 缺点：同步阻碍 脑裂 单点问题  太过保守

同步阻塞

三阶段提交

将第二阶段提交一分为二  形成了can commit、 pre commit   和do commit

Can commit

1 事务询问

协调者向参与者 询问是否能不能cancommit 请求 并等待参与者响应。

2 各参与者响应向协调者 反映能否提交请求。
pre commit

假如所有反馈者反馈yes 就进入预提交。

1. 发送预提交请求

   协调者向参与者发送预提交 请求并进入prepared

 

1. 参与者接收到pre commit  进行事务执行 记录到undo 和redo 事务日志中
2. 各参与者向协调者反馈事务执行的响应

发送ack 并等待最终指令 提交或者 中止

   

             中断事务

              参与者反馈no 或者超时 就会中断。

              1 协调者向参与者发送abort  请求

              2 参与者中断事务

               收到协调者abort 或者等待超时。

             阶段三 dommmit 操作

              执行提交

             发送提交请求：

              1接收到所有参与者的ack 响应 从预提交 转换成提交状态。并向参与者发dommimit 请求

              2  事务提交

               所有参与者完成事务提交 并释放所占的事务资源。

              3  反馈事务提交结果

                 参与者向协调者反馈事务提交结果

1. 完成事务

协调者接收到所有参与者的反馈。完成事务。

中断事务

1 协调者发送中断请求

2 参与者执行事务回滚

3 反馈事务回滚结果

4中断事务

优缺点

优点：减少了阻塞范围

缺点：Paxos 算法

基于消息传递且高度容错的算法

拜占庭将军问题

 

Zab 协议

所有事务请求必须由全局唯一的服务器来协调处理，也就是leader 服务器，而余下的服务器被称为follower 服务器。Leader 服务器 会将客户端事务提议 分发 各个follower 并等待反馈，如果超过半数以上的反馈正常，leader 服务器会再次 向追随者发出commit  并将客户端事务进行提交。

Zab  两种基本模式 

1崩溃恢复 2 消息传播