从Paxos算法到Zookeeper

引

分布式系统问题：

• 数据同步延时（不一致） – 访问的不是最新数据
• 节点被杀死（宕机）–客户端访问节点的数据访问不了

分布式系统节点通信模型：

共享内存、消息传递

---

Paxos算法 --> 高容错性

Paxos提出了一种基于消息传递并且具有高容错性的一致性算法

1.Paxos算法角色：

• 提议者（主）：发起提案 – 开启一个事物、多个节点同步数据
• 接受者（从）：接受、拒绝提案
• 学习者（类似从）：只能接受提案，不能拒绝

2.补充说明：

所有的事务必须由一个全局唯一的服务器进行处理 – leader服务器(负责把客户端的事务请求转换消息，传递给follower服务器、之后leader服务器要等待所有的follower服务器反馈；所有的follower反馈超过半数以上这个提案才能生效
半数通过：

• 选举leader，一半的人拥护这个人
• 有了leader之后，至少要有一半的数据写成功，才算成功
• HDFS -->namenode挂了 整个集群就不可用了
• Zookeeper -->1个leader，9个follower，1个observer 10个节点挂了 集群才不可用

---

抽屉原理/鸽巢原理 --> 一致性

1.鸽巢原理

第一鸽巢原理：如果K+1个或者更多的物体放在k个盒子里，那么至少有一个盒子包含了两个或者更多的物体
第二鸽巢原理：把m×n+1只鸽子放到n个笼子，所有的鸽子都被关进笼子里，那个至少有一个笼子有m+1只鸽子
第三无穷项集鸽巢原理：把无穷多只鸽子放入笼子，则至少有一个笼子里有无穷只鸽子
图
在分布式系统中的应用：

• 所有节点持有整个系统完整的数据
• 集群中所有节点中的数据文件都有编号，新文件的编号大于旧文件

2.NWR机制

分布式场景中常用的，用来保证数据安全的，能够保证在分布式环境中实现最终一致性的投票算法，源于鸽笼原理，保证客户端能够读取到最新的数据

**
N：复制的节点数
W：写操作成功的节点数（W一定小于等于N）
R：读操作获取最新版本的数据，需要读取的最小节点个数
W+R>N

---

CAP理论

CAP 理论含义：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
https://www.cnblogs.com/itzlg/p/13161173.html

选项	描述
C 一致性	分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
A 可用性	Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
P 分区容错性	系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务

ps:强一致性和高可用冲突

CAP定义

Consistency 一致性

• 对于客户端：一致性主要指的是多并发访问时更新过的数据如何获取的问题
• 对于服务端：更新如何复制分布到整个系统，以保证数据最终一致
• CAP中说，不可能同时满足的这个一致性指的是强一致性

Availability 可用性

• 一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应，不出现用户操作失败或者访问超时
• 衡量一个系统的可用性：计算停机时间

Partition Tolerance分区容错性

• 网络分区概念：一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。
• 当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。
• 提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里，容忍性就提高了
  • —> 要把数据复制到多个节点，就会带来一致性的问题
  • —> 为了保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题

总结：数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低

CAP权衡

一般做法：满足P --> 进行A C选择

• 舍弃A，保留CP：在极端情况下，允许出现系统无法访问的情况，用户请求不确定返回时间，会牺牲用户体验

— ZooKeeper是个CP，在极端环境下，ZooKeeper可能会丢弃一些请求
— ZooKeeper是分布式协调服务，它的职责是保证数据在其管辖下的所有服务之间保持同步、一致

• 舍弃C，保留A****P：是大部分分布式系统的设计，保证高可用和分区容错

— 12306买票 买的时候有 下单的时候提示失败 余票不足

• 舍弃P，保留CA：也就是舍弃分布式系统，即P是分布式系统的前提,这种情况是不存在的

---

BASE理论

BASE全称: Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写
BASE理论核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性

基本可用

• 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性（一个操作可能会有响应延时）
• 例子: 响应时间上的损失, 功能上的损失
• 场景：整个系统资源不够用了，暂停某些边缘业务，保留重要业务

软状态

• 硬状态：相对于一致性，要求多个节点的数据副本都是一致的
• 软状态：允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟

最终一致性

• 最终一致性是系统中所有的数据副本在经过一段时间的同步后最终达到一致的状态

---

Zookeeper

Zookeeper
ZooKeeper是一个分布式、开源的分布式应用程序协调服务，由雅虎创建，是Google Chubby的开源实现。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

基本功能

• 文件系统–Zookeeper维护一个类似文件系统的数据结构

• 监听机制–客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端

实现服务

• 分布式同步
• 集群管理
• 命名管理
• 队列管理
• 服务器上下线动态感知（心跳机制）
• 分布式锁

Zookeeper架构设计特点

• 最终一致性
  • 无论客户端连接那一台server（服务器），都能得到一模一样的数据视图
• 可靠性
  • 如果消息能够被服务器接收，那么所有服务器必须接受
  • hadoop02(写) hadoop03(写) hadoop04,超过半数写成功了，进行数据同步的节点必须接受
• 顺序性（全局时钟）
  • leader发送的数据是有因果顺序的
  • 全局有序：如果一台服务器发送A消息在B消息前，所有服务器在做数据同步时，A消息永远在B消息前，所有的消息在分布式集群里面都是全局有序的
• 原子性
  • 事务要么成功，要么失败（失败就回滚）

---