加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

Zookeeper技术:分布式架构详解、分布式技术详解、分布式事务

发布时间:2019-10-16 00:25:02 所属栏目:优化 来源:Ja高级互联网架构
导读:副标题#e# 一、分布式架构详解 1、分布式发展历程 1.1 单点集中式 特点:App、DB、FileServer都部署在一台机器上。并且访问请求量较少 1.2 应用服务和数据服务拆分 特点:App、DB、FileServer分别部署在独立服务器上。并且访问请求量较少 1.3 使用缓存改善

示例2:交叉场景

Zookeeper技术:分布式架构详解、分布式技术详解、分布式事务

角色:

proposer:参谋1,参谋2

acceptor:将军1,将军2,将军3(决策者)

1)参谋1发起提议,派通信兵带信给3个将军,内容为(编号1);

2)3个将军的情况如下

a)将军1和将军2收到参谋1的提议,将军1和将军2把(编号1)记录下来,如果有其他参谋提出更小的编号,将被拒绝;同时让通信兵带信回去,内容为(ok);

b)负责通知将军3的通信兵被抓,因此将军3没收到参谋1的提议;

3)参谋2在同一时间也发起了提议,派通信兵带信给3个将军,内容为(编号2);

4)3个将军的情况如下

a)将军2和将军3收到参谋2的提议,将军2和将军3把(编号2)记录下来,如果有其他参谋提出更小的编号,将被拒绝;同时让通信兵带信回去,内容为(ok);

b)负责通知将军1的通信兵被抓,因此将军1没收到参谋2的提议;

5)参谋1收到至少2个将军的回复,再次派通信兵带信给有答复的2个将军,内容为(编号1,进攻时间1);

6)2个将军的情况如下

a)将军1收到了(编号1,进攻时间1),和自己保存的编号相同,因此把(编号1,进攻时间1)保存下来;同时让通信兵带信回去,内容为(Accepted);

b)将军2收到了(编号1,进攻时间1),由于(编号1)小于已经保存的(编号2),因此让通信兵带信回去,内容为(Rejected,编号2);

7)参谋2收到至少2个将军的回复,再次派通信兵带信给有答复的2个将军,内容为(编号2,进攻时间2);

8)将军2和将军3收到了(编号2,进攻时间2),和自己保存的编号相同,因此把(编号2,进攻时间2)保存下来,同时让通信兵带信回去,内容为(Accepted);

9)参谋2收到至少2个将军的(Accepted)内容,确认进攻时间已经被多数派接受;

10)参谋1只收到了1个将军的(Accepted)内容,同时收到一个(Rejected,编号2);参谋1重新发起提议,派通信兵带信给3个将军,内容为(编号3);

11)3个将军的情况如下

a)将军1收到参谋1的提议,由于(编号3)大于之前保存的(编号1),因此把(编号3)保存下来;由于将军1已经接受参谋1前一次的提议,因此让通信兵带信回去,内容为(编号1,进攻时间1);

b)将军2收到参谋1的提议,由于(编号3)大于之前保存的(编号2),因此把(编号3)保存下来;由于将军2已经接受参谋2的提议,因此让通信兵带信回去,内容为(编号2,进攻时间2);

c)负责通知将军3的通信兵被抓,因此将军3没收到参谋1的提议;

12)参谋1收到了至少2个将军的回复,比较两个回复的编号大小,选择大编号对应的进攻时间作为最新的提议;参谋1再次派通信兵带信给有答复的2个将军,内容为(编号3,进攻时间2);

13)将军1和将军2收到了(编号3,进攻时间2),和自己保存的编号相同,因此保存(编号3,进攻时间2),同时让通信兵带信回去,内容为(Accepted);

14)参谋1收到了至少2个将军的(accepted)内容,确认进攻时间已经被多数派接受。

四. Zookeeper ZAB协议

Zookeeper Automic Broadcast(ZAB),即Zookeeper原子性广播,是Paxos经典实现

术语:

quorum:集群过半数的集合

1. ZAB(zookeeper)中节点分四种状态

looking:选举Leader的状态(崩溃恢复状态下)

following:跟随者(follower)的状态,服从Leader命令

leading:当前节点是Leader,负责协调工作。

observing:observer(观察者),不参与选举,只读节点。

2. ZAB中的两个模式(ZK是如何进行选举的)

崩溃恢复、消息广播

Zookeeper技术:分布式架构详解、分布式技术详解、分布式事务

1)崩溃恢复

leader挂了,需要选举新的leader

Zookeeper技术:分布式架构详解、分布式技术详解、分布式事务

a.每个server都有一张选票,如(3,9),选票投自己。

b.每个server投完自己后,再分别投给其他还可用的服务器。如把Server3的(3,9)分别投给Server4和Server5,一次类推

c.比较投票,比较逻辑:优先比较Zxid,Zxid相同时才比较myid。比较Zxid时,大的做leader;比较myid时,小的做leader

d.改变服务器状态(崩溃恢复->数据同步,或者崩溃恢复->消息广播)

相关概念补充说明:

epoch周期值

acceptedEpoch(比喻:年号):follower已经接受leader更改年号的(newepoch)提议。

currentEpoch(比喻:当前的年号):当前的年号

lastZxid:history中最近接收到的提议zxid(最大的值)

history:当前节点接受到事务提议的log

Zxid数据结构说明:

cZxid = 0x10000001b

64位的数据结构

高32位:10000

Leader的周期编号+myid的组合

低32位:001b

事务的自增序列(单调递增的序列)只要客户端有请求,就+1

当产生新Leader的时候,就从这个Leader服务器上取出本地log中最大事务Zxid,从里面读出epoch+1,作为一个新epoch,并将低32位置0(保证id绝对自增)

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读