数据发布订阅/ 配置中心
实现配置信息的集中式管理和数据的动态更新
实现配置中心有两种模式:
push:服务器主动将数据的更新发送给客户端
pul:客户端主动去发起请求去获取新的配置数据
长轮训
通过http请求建立一个长轮训的机制,客户端主动去监控服务的配置的变化,发生变化后主动将配置拉取到本地
zookeeper采用的是推拉相结合的方式
客户端向服务器端注册自己需要关注的节点。一旦节点数据发生变化,那么服务器端就会向客户端发送watcher事件通知。客户端收到通知后,主动到服务器端获取更新后的数据
一般客户端都会维护一个类似properties的配置文件,客户端第一次项目启动时会主动去服务端 pull 所关注的配置信息,并生成一个缓存文件保存到本地,后续有配置更新时再去更新之前的配置文件,客户端依赖的配置都是从缓存文件中读取,防止每次启动服务再pull,提高效率
配置数据特征:
- 数据量比较小
- 数据内容在运行时会发生动态变更
- 集群中的各个机器共享配置
负载均衡
请求/数据分摊多个计算机单元上
分布式锁
通常实现分布式锁有几种方式
-
redis setNX 命令实现
-
数据库方式实现
创建一个表, 通过索引唯一的方式
create table (id , methodName …) methodName 增加唯一索引
insert 一条数据 methodName == XXX 成功的获取锁,失败的等待或者返回,释放锁则使用delete 语句删除这条记录,如果出现delete失败会导致后面所有的进程都无法获取到锁
mysql for update innerDB 引擎,设置行锁,这种属于独占锁
-
zookeeper实现
排他锁,A/B/C 三个客户端都去 Locks创建一个临时子节点,成功则获取到锁,其他客户端等待
共享锁(读锁)
实现共享锁,使用java api的方式
命名服务
master选举
7*24小时可用, 99.999%可用
master-slave模式
使用zookeeper解决
分布式队列
zookeeper集群角色
leader
leader是zookeeper集群的核心。
- 事务请求的唯一调度者和处理者,保证集群事务处理的顺序性
- 集群内部各个服务器的调度者
follower
- 处理客户端非事务请求,以及转发事务请求给leader服务器
- 参与事务请求提议(proposal)的投票(客户端的一个事务请求,需要半数服务器投票通过以后才能通知leader commit; leader会发起一个提案,要求follower投票)
- 参与leader选举的投票
observer
观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上
增加observer不影响集群中事务处理能力,同时还能提升集群的非事务处理能力
zookeeper的集群组成
zookeeper一般是由 2n+1台服务器组成
leader选举
leaderElection/AuthFastLeaderElection/FastLeaderElection
QuorumPeer startLeaderElection
源码分析
源码地址:https://github.com/apache/zookeeper.git
需要的条件: jdk 1.7以上 、ant 、idea
FastLeaderElection
serverid : 在配置server集群的时候,给定服务器的标识id(myid)
zxid : 服务器在运行时产生的数据ID, zxid的值越大,表示数据越新
Epoch: 选举的轮数
server 的状态:Looking、 Following、Observering、Leading
第一次初始化启动的时候: LOOKING
- 所有在集群中的server都会推荐自己为leader,然后把(myid、zxid、epoch)作为广播信息,广播给集群中的其他server, 然后等待其他服务器返回
- 每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后,开始判断投票的有效性
- 判断逻辑时钟(Epoch) ,如果Epoch大于自己当前的Epoch,说明自己保存的Epoch是过期。更新Epoch,同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况
- 如果Epoch小于目前的Epoch,说明对方的epoch过期了,也就意味着对方服务器的选举轮数是过期的。这个时候,只需要讲自己的信息发送给对方
ZAB协议
拜占庭问题
paxos协议主要就是如何保证在分布式环网络环境下,各个服务器如何达成一致最终保证数据的一致性问题
ZAB协议,基于paxos协议的一个改进。
zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议
zookeeper并没有完全采用paxos算法, 而是采用zab Zookeeper atomic broadcast
zab协议的原理
-
崩溃恢复
-
原子广播
- 在zookeeper 的主备模式下,通过zab协议来保证集群中各个副本数据的一致性
- zookeeper使用的是单一的主进程来接收并处理所有的事务请求,并采用zab协议,把数据的状态变更以事务请求的形式广播到其他的节点
- zab协议在主备模型架构中,保证了同一时刻只能有一个主进程来广播服务器的状态变更
- 所有的事务请求必须由全局唯一的服务器来协调处理,这个的服务器叫leader,其他的叫follower
leader节点主要负责把客户端的事务请求转化成一个事务提议(proposal),并分发给集群中的所有follower节点,再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈,那么leader就会commit这条消息
zab协议的工作原理
什么情况下zab协议会进入崩溃恢复模式
- 当服务器启动时
- 当leader服务器出现网络中断、崩溃或者重启的情况
- 集群中已经不存在过半的服务器与该leader保持正常通信
zab协议进入崩溃恢复模式会做什么
- 当leader出现问题,zab协议进入崩溃恢复模式,并且选举出新的leader。当新的leader选举出来以后,如果集群中已经有过半机器完成了leader服务器的状态同(数据同步),退出崩溃恢复,进入消息广播模式
- 当新的机器加入到集群中的时候,如果已经存在leader服务器,那么新加入的服务器就会自觉进入数据恢复模式,找到leader进行数据同步
问题
假设一个事务在leader服务器被提交了,并且已经有过半的follower返回了ack。 在leader节点把commit消息发送给folower机器之前leader服务器挂了怎么办?
zab协议需要保证 已经被leader提交的事务也能够被所有follower提交
zab协议需要保证 在崩溃恢复过程中跳过哪些已经被丢弃的事务