Zookeeper是什么
- Zookeeper是一个开源的分布式协调框架。它是一个为分布式应用提供服务的软件。
Zookeeper有哪些功能
集群管理
- 监控节点的存活状态、运行请求等
主节点的选举
- 主节点挂掉之后，可以从备用的节点开始新一轮的选主。
分布式锁
:::info
- Zookeeper提供了两种分布式锁机制。
- 独占锁：一次只能有一个线程使用资源。
- 共享锁：共享锁是读锁共享，读写互斥。即：可以有多个线程同时读取同一个资源，如果要使用写锁，也只能有一个线程使用。
:::
命名服务
:::tips
- 在分布式系统中，可以使用命名服务，客户端应用能够指定名字来获取资源或服务地址、提供者等信息。
:::
CAP原则
C：Consistency（一致性）
:::warning
- 系统在执行某个操作后，仍然处于一致的状态。即在同一时刻中，要保持同样的值。
:::
A：Availability（可用性）
:::warning
- 只要用户发起请求，系统就必须及时响应。响应越快，可用性越好。
- 并且每个请求不管成功或者失败都有响应。
:::
P：Partition Tolerance（分区容错性）
:::warning
- 系统中任意信息的丢失或失败不会影响系统的继续运作。
:::
CPA原则
:::info
- CPA原则，是分布式系统参考的三个重要指标。具体是指Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性。
- CPA原则指出，在一个分布式系统中，不可能同时满足三者。而分区容错性一般是必须具备的重要指标，这也是分布式系统的初衷。因此，实际的业务架构设计中，往往都是对C（一致性）和A（可用性）的权衡和取舍。
:::
Zookeeper是PC架构
Eureka是AP架构
数据的一致性
:::tips
- 在分布式系统中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。
:::
强一致性
:::tips
- 要求无论更新操作是在哪一台服务器执行，之后所有的读操作都能够获取到最新的数据。
:::
弱一致性
:::tips
- 读取到的数据可能不是最新的数据。
:::
最终一致性
:::tips
- 客户端：有可能客户端当前获取的不是最新数据，但是最终还是能访问到最新的。
- 服务端：数据存储并复制到整个分布式系统中，只要超过一半以上的节点，就认为数据操作成功。
:::
Paxos算法
- Paxos算法：是一种基于消息传递且具有高度容错性的一致性算法。
:::success
Paxos算法解决的问题：
- 就是如何快速、正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。
:::
无主集群模型
人人平等，人人都有发送指令和投票的权力。
- 缺陷：
- 导致活锁问题。
- 事务编号混乱，每个节点都有可能有自己的提议。
有主集群模型
- 只能有一个主发送指令，发送提议。
- 缺陷：
- 单点故障。
- 如果存在多个主就会脑裂。
单点故障，从新选举
单点故障
- 重新选举，议员会把票投给数字编号（myid）和事务编号（ZXID）都大于自己的议员。
- 选举过程中，先比较ZXID（为了确定谁的数据是最安全的）。如果ZXID相同，再比较myid。
脑裂出现的原因
:::danger
脑裂出现的原因
- 由于网络波动，将集群分成两块，没有主的集群，就会重新选举。过半原则，如果某个议员获得超过半数以上的选票，就可以成为新主。
- 当网络恢复后，发现集群中存在多个主，就出现了脑裂。
:::
活锁问题
:::danger
活锁
-
事物1可以使用资源，但它让其它事物先使用资源。事物2可以使用资源，但它也让其它事物先使用资源，于是两者一直谦让，都无法使用资源。
-
多个线程争用同一个资源，但是没有任何一个线程能拿到这个资源。
- 活锁是死锁的变种。活锁最终的危害，就是会耗尽CPU资源。（在做无意义的调度）
-
死锁：
- 死锁是有一个线程拿到资源，但相互等待互不释放资源，造成死锁。
:::
- 死锁是有一个线程拿到资源，但相互等待互不释放资源，造成死锁。
Raft算法
Raft算法适用于管理日志一致性的协议。
Raft一致性算法分为：
:::info
- Leader选取。
- 日志复制。
- 安全。
:::
Raft协议的角色
Leader
接受客户端请求并向Follower同步请求日志。当日志同步到大多数节点上后，告诉Follower提交日志。
Follower
被动响应请求，从不主动发起请求。接受并持久化Leader同步的日志。
Candidate
候选者，Leader选举时的一种临时角色。只存在Leader的选举阶段，某个节点想要变成Leader，那么就发起投票请求，同时自己会变成Candidate。
ZAB协议
:::info
- 消息广播
- 崩溃恢复
:::
ZAB协议与Paxos算法的联系与区别
:::success
相同点：
- 两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行。
- Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交。
- ZAB协议中，每个Proposal中都包含一个Epoch值来代表当前Leader的周期，Paxos中名字为Ballot。
不同点：
- ZAB协议用来构建高可用的分布式数据主备系统（Zookeeper），Paxos算法是用来构建分布式一致性状态的系统。
:::
Zookeeper的常用命令
:::success
开启Zookeeper服务：
**zkServer.sh start**
查看Zookeeper服务的状态：
**zkServer.sh starts**
关闭Zookeeper服务：
**zkServer.sh stop**
:::
Zookeeper的存储模型
Zookeeper的存储结构
- Zookeeper是一种树状结构内存模型，类似文件系统。
- 只是在Zookeeper中将这些目录与文件统称为ZNode，ZNode是Zookeeper中数据的最小单元。
- 每个ZNode上都可以保存数据，还可以挂载子节点。（因此构成了一个层次化的命名空间）
- 数据以K-V的方式存在，目录作为数据的key。
- 所有的数据访问都必须以绝对路径的方式开始（即：以
**/**开始）。- 每个节点存放数据的上限为1M。
Zookeeper的节点分类【两类四种】
1、持久化节点Persistent
:::success
- 默认创建的节点，就是持久化节点。除非手动删除，否则节点一直存在在Zookeeper上。
:::
2、序列化持久节点Sequential
3、临时节点Ephemral
:::success
- 只要创建节点的会话有效，节点就不会失效。
- 可以被所有的客户端所查看。
- 事务编号和临时节点的编号是一致的。
- 一旦会话结束，临时节点也会被自动删除。（一般这个功能用于判断，节点和服务器是否保持连接）
:::
4、序列化临时节点Sequential
Zookeeper是如果保证事务的顺序一致性
:::info
- Zookeeper采用了全局递增的事务id（
**ZXID**）来标识，所有的Proposal（提议）都在被提出的时候加上ZXID。- ZXID实际上是一个64位的数字，高32位是Epoch（任期），用来标识Leader的周期。如果有新的Leader产生出来，Epoch（任期）会自动增长。
- 低32位按照数字递增，每次客户端发送一个Proposal（提议）的时候，低32位的数字会自动增1。
:::
Zookeeper的选举机制
第一次启动时：
:::warning
过半原则，服务器id（myid）大的会被选举为Leader。
:::
Leader挂掉时：
:::warning
- 首先会根据任期选择。
- 任期相同，再根据ZXID（事务id）大的
- ZXID（事务id）如果相同，再根据服务器id（myid）大的会被选举为Leader。
:::
:::tips
生产环境下，Zookeeper的安装经验：
- 10台服务器：3台Zookeeper
- 20台服务器：5台Zookeeper
- 100台服务器：11台Zookeeper
- 200台服务器：11台Zookeeper
- 服务器的台数多：
- 好处：提高可靠性。
- 坏处：提高通信延时。
:::
- 服务器的台数多：
Zookeeper下的Server工作状态
1、Looking
:::info
- 寻找Leader状态。
- 当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
:::
2、Following
:::info
- 跟随者状态。
- 表示当前服务器角色是Follower。
- 处理客户端的非事务请求，转发事务请求给Leader服务器。
- 参与事务请求Proposal的投票。
- 参与Leader选举投票。
:::
3、Leading
:::info
- 领导者状态。
- 表示当前服务器角色是Leader。
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
:::
4、Observing
:::info
- 观察者状态。
- 表示当前服务器角色是Observer。
- Observer的工作原理和Follower的工作原理基本一致，区别在于Observer不参与任何形式的投票。
- 3.0版本以后引入的一个服务器角色。可以处理客户端的非事务请求，转发事务请求给Leader服务器。
- 不会参与任何形式的投票。
:::
Zookeeper怎么保证主从节点的状态同步
:::tips
Zookeeper的核心是原子广播机制，这个机制保证了各个Server之间的同步。实现这个机制的协议叫ZAB协议。
:::
- ZAB协议有两种模式：
- 恢复模式。
- 当服务器启动或在Leader崩溃后，ZAB就进入了恢复模式。当Leader被选举出来，且大多数Server了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。
- 广播模式。
- 一旦Leader已经和多数的Follower进行了状态同步后，它就可以开始广播消息了，即进入广播状态。这时候当一个Server加入Zookeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Follower支持。
SSH免密登录原理
877
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
