一、分布式架构

1.集中式系统：指一台或多台计算机组成中心节点，系统的所有业务和数据都部署在这个节点上。

优点：部署结构简单。缺点：价格昂贵，存在明显的单点问题(一旦一台大型主机出现故障，整个系统

将处于不可用状态)。

2.分布式系统：指硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通讯

和协调。特征有：

分布性：计算机在空间上随意分布。

对等性：计算机没有主/从之分,节点都是对等的。

并发性：多个节点可能会并发地操作一些共享资源。

缺乏全局时钟：不能区分事件的先后。

故障总是会发生

3.分布式事务满足ACID(原子性、一致性、隔离性、持久性)
4.CAP定理：一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能满足

其中的两项。三个特性如下：

一致性(Consistency)：指数据在多个副本之间保持一致。一个数据更新后，所有的用户能看到最新的值。

可用性(Availability)：指系统提供的服务必须一直处于可用的状态，对用户的每一个操作请求总是能够在有限的时间内返回结果。

分区容错性(Partition tolerance)：在遇到任何网络分区故障的时候，任然需要能够对外提供满足一致性和可用性的服务，除非是整个网络

环境都发生了故障。

CAP定理应用：放弃A或放弃C或放弃P。

5.BASE理论是对CAP中的一致性和可用性的权衡结果。即使无法做到强一致性，也可以采用适当的方法达到最终一致性。

BASE三要素：

基本可用：系统在发生不可预知的故障时，允许损失部分的可用性(包括响应时间、功能上的损失)。

弱状态：也叫软状态，与硬状态相对。存在中间状态，允许系统在不同节点的数据副本在进行数据同步的时候存在延时。

最终一致性：系统的所有数据副本，经过一段时间以后，最终能够达到一致的状态，不需要实时保证数据的强一致性。

二、一致性协议

1.2PC:(包含协调者和参与者) 二阶段协议。分为两个阶段：阶段一：提交事务请求；阶段二：执行事务提交。

执行过程：协调者向对所有参与者进行询问，看它们是否都需要事务提交，若都需要则进行事务提交；当事务提交后，协调者接收

反馈信息，若反馈No响应或等待超时后，就会中断事务，协调者向所有参与者发出回滚请求。

优缺点：

同步阻塞：提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态。

单点问题：如果协调者出现问题，其他参与者将处于锁定状态，无法继续完成实务操作。

数据不一致：在执行事务提交的时候，可能会出现只有部分参与者接收到提交请求，导致数据不一致。

太过保守：没有完善的容错机制，只要一个节点失败就导致整个事务失败。

2.3PC：三阶段协议。对二阶段协议进行改进，分为CanCommit、PreCommint(预提交)、doCommit阶段，多了预提交阶段。

执行过程：协调者向对所有参与者进行询问，看它们是否都需要事务提交，若都需要则进行事务预提交；在事务预提交中，协调者接收

反馈信息，若反馈No响应或等待超时后，就会中断事务;若预提交执行成功，则进行真正的事务提交。

优缺点：

优点：降低参与者的阻塞范围，能够在出现单点故障后继续达成一致。

缺点：在PreCommit后，如果出现网络分区，协调者所在的节点和参与者无法进行正常网络通信，导致数据不一致性。

3.Paxos算法：

包含的角色有：Proposer(申请者)、Acceptor(接收者)、Learner(领导者);

执行过程：

提案的选定：一个Proposer向一个或多个Acceptor发提案，由半数以上Acceptor批准的提案会被选定。

Proposer生成提案：在确定提案后，Proposer会将该提案再次发送给某个Acceptor集合，并期望获得它们的批准。

Acceptor批准提案：Aceeptor接到Proposer的Prepare或Accept请求后，做出相应的响应。

提案的获取：Learner获取提案。

优点：引入“过半”的概念，即少数服从多数的原则，并且支持节点角色之间的轮换，极大地避免了分布式的出现，也解决了

无限等待和“脑裂”等问题。

三、Paxos工程实践

1.Chubby是一个分布式锁服务，底层一致性实现是以Paxos算法为基础的。

应用场景：集群服务器中的Master选举。

Chubby系统结构主要由服务端和客户端两部分组成，客户端通过RPC调用与服务器进行通信。

客户端可以向服务端注册事件通知，当触发这些事件的时候，服务端就会向服务端发送对应的事件通知。

Chubby中一些关键词：锁与锁序列器、缓存、会话和会话激活、故障恢复、Paxos协议实现。

2.Hypertable：构建一个针对分布式海量数据的高并发数据库。

只支持基本的添、删、改、查，还没有支持事务处理和关联查询等特性。

核心组件有：

Hyperspace：提供对分布式锁服务的支持和及对元数据的管理，是保证数据一致性的核心。

RangeServer：提供对外服务，负责数据的读取和写入。

Master：元数据管理中心。

DFS Broker：底层分布式文件系统的抽象层。

四、Zookeeper

1.zookeeper是一个典型的分布式数据一致性的解决方法，可以实现数据发布/订阅、负载均衡、命名服务、

分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

zookeeper将全量数据存储在内存中，来实现提高服务器吞吐、减少延迟的目的。

2.基本概念；

集群角色：没有Master/Slave概念，有Leader、Follower、Observer三个角色。Leader服务器为客户端提供

读和写服务。Follower和Observer都能提供读服务，但Observer不参与Leader选举过程。

会话：指客户端和服务器之间的一个TCP连接。

节点：机器节点（集群中的机器），数据节点（Znode数据模型中的数据单元,分为持久节点和临时节点）

版本：version、cversion等

Watcher:可在指定的节点上注册事件，当事件触发的时候，服务器会通知客户端。

ACL：用来进行权限控制。

3.ZAB协议：是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。

ZAB协议包括两种基本模式：崩溃恢复和消息广播。

在消息广播中，Leader服务器会为每一个Follower服务器各自分配一个单独的队列，将需要广播的事务依次放入

这些队列中，并根据FIFO的策略进行消息发送。

崩溃恢复：当Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去与过半Follower的联系，就进入崩溃恢复模式。

进程正常工作时，处于UP状态;进程崩溃时，称为处于DOWN状态。

ZAB协议是整个Zookeeper框架的核心所在，它规定任何时候都需要保证只有一个主进程负责进行消息广播，如果主进程崩溃了

就要选举一个新的主进程，选举机制和消息广播机制是紧密相关。

ZAB与Paxos的联系与区别：

联系：都存在类似于Leader进程的角色，负责协调多个Follower进程的运行;Leader进程都会等待超过半数的Follower做出正确

的反馈后，才会将一个提案进行提交。

区别：设计目标不一样。ZAB用于构建一个高可用的分布式数据主备系统，Paxos用于构建分布式一致性状态机系统。

五、使用Zookeeper

1.部署与运行：
Zookeeper使用Java编写，需要Java环境的支持。
2.运行模式：集群模式、单机模式(只有一台机器)。
3.配置zoo.cfg、创建myid文件等。
4.伪集群模式：在同一台机器上的不同端口上启动不同的进程。
5.可执行脚本：zkCleanUp、zkCli、zkEnv、zkServer等。
6.Java客户端API中节点操作：创建、更新、删除、读取等(每个路径对应一个节点)。
7.检测节点是否存在、权限控制、事件监听、Master选举、分布式锁。
8.开源客户端：ZkClient、Curator。

六、Zookeeper应用

一些关联的技术：
Hadoop：Apache开源的大型分布式计算框架。它的核心是HDFS和MapReduce，分别提供对海量数据的存储和计算能力。
YARN：为了提高计算节点的分布式调度框架，可以支持MapReduce、Spark、Storm等计算引擎。
HBase：Hadoop Database，是基于Hadoop文件系统设计的面向海量的数据高可靠性、高性能、面向列、可伸缩的
分布式存储系统，可以在廉价的PC服务器上搭起大规模结构化的存储集群。对数据写入具有强一致性。
Kafka：由Scala语言开发、吞吐量极高的分布式消息系统，可以用于实现低延迟的发送和收集大量的事件和日志数据。
它包含：消息生产者Producer、消息消费者Consumer、主题Topic、消息分区(一个Topic下可以有多个分区)、
Broker(服务器，用于存储消息)、消费者分组Group、Offset(消息在文件中的偏移量)。
Broker注册、Topic注册、生产者和消费者负载均衡、消费进度Offset记录。

七、Zookeeper技术内幕

1.在Zookeeper中，每一个数据节点都称为一个ZNode，所有的ZNode按层次化结构进行组织，形成一棵树。
2.Zookeeper中的事务：指能够改变服务器状态的操作，比如节点的创建、删除等。每一个事务请求都会有

一个全局唯一的事务ID。

3.节点特性：

节点类型(节点的生命周期)：持久节点、临时节点、顺序节点。

状态信息：包含事务ID、创建时间、版本号等信息。

版本：记录节点的修改次数，用来保证分布式数据的原子性操作（悲观锁：一个事务对数据进行处理时，在整个过程

都将数据锁定，其它事务无法对这个数据进行更新，直到这个事务完成;乐观锁：假定多个事务在处理过程中不会彼此影响，所以

在大部分时间不需要加锁）

4.Watcher:客户端向服务端注册一个Watcher，当服务端指定事件触发时，就会向指定的客户端发送一个事件通知。

Watcher接口、WatchedEvent、回调方法等等。

5.ACL：“schema:id:permission”

schema权限模式：

IP:通过IP地址粒度进行权限控制。

Digest:类似于“username:password”形式。

World:对所有用户开放。

Super:对超级用户开放。

授权对象ID：指权限赋予的用户或一个指定实体。

权限Permission:CREATE(创建权限)、DELETE(删除权限)、READ(读取权限)、WRITE(更新权限)、ADMIN(管理权限)。

6.序列化：使用Jute实现序列化和反序列化。
7.通信协议：Zookeeper基于TCP/IP协议，实现了自己的通信协议来完成客户端与服务器、服务器与服务器之间的网络通信。

对于请求主要包括请求头和请求体，对于响应，主要包含响应头和响应体。

8.解析服务器地址：将多个服务器地址打散后，装入一个循环队列中，然后再遍历选取。
9.ClientCnxn网络IO：负责维护客户端与服务端之间的网络连接并进行一系列的网络通信。
10.会话：在Zookeeper客户端和服务端成功完成连接创建后，就建立了一个会话，在运行期间会在不同的回话状态

之间进行切换。会话状态有CONNECTING、CONNECTED、CLOSE等等。

会经历会话创建，会话检查，会话删除等。

11.Leader选举：

服务器启动时期的选举：(1)每个Server发出一个投票（以(myid,ZXID)表示，myid表示要投的服务器，初始时都会投给自己）；

(2)接收来自各服务器的投票（判断投票的有效性）；(3)处理投票（将别人的投票和自己的投票PK，先比较ZXID，若相同再比较myid，

比较大的作为Leader）；(4)统计投票（每次投票后，统计是否有过半的机器接收到相同的投票信息）；(5)改变服务器状态

（选出Leader后，就更改状态，FOLLOWING、LEADING）

服务器运行期间的选举：在运行时候，当Leader所在的机器挂掉时，就会进行新一轮的Leader选举，先把其余服务器状体变为LOOKING

其余选举过程和启动时选举一致。

服务器状态：LOOKING(寻找Leader状态)、FOLLOWING(跟随者状态)、LEADING(领导者状态)、OBSERVING(观察者状态)。

12.服务器中的角色：

Leader:事务请求的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各服务器的调度者。

Follower:处理客户端非事务请求，转发事务请求给Leader服务器；参数事务请求Proposal投票；参与Leader选举投票。

Observer：和Follower基本是一致的，只是不参与任何形式的投票。

13.集群间消息通信：

分为数据同步型、服务器初始化型、请求处理型和会话管理型。

14.Proposal流程：每一个事务请求都需要集群中过半机器投票认可才能被应用到Zookeeper的内存数据库中去。

包括(1)发起事务投票；(2)生成提议Proposal；(3)广播提议；(4)收集投票；(5)将请求放入toBeApplied队列；(6)广播COMMIT消息

15.数据与存储：分为内存数据存储和磁盘数据存储。

内存数据：DataTree(是一颗树结构，代表一份完整的数据)，DataNode(数据存储的最小单元)，

ZKDatabase是Zookeeper的内存数据库，负责管理Zookeeper的所有会话、DataTree存储和事务日志。

数据快照：用来记录Zookeeper服务器上某一个时刻的全量内存数据内容，并将其写入到指定的磁盘文件中。

数据同步：将没有在Leader服务器上提交过的事务请求同步给Leader服务器。