读《从paxos到zookeeper分布式一致性》

Posted on Edited on

[TOC]

一致性协议

  • question：为什么说两阶段提交时，参与者同步阻塞，等待其他参与者响应时，无法进行其他任何操作？
  • res：

角色类型

  1. leader：提供读写
  2. follower：提供读，参与leader选举
  3. observer：提供读

数据节点

  1. 机器节点
  2. 数据节点-Znode

watcher

ACL(Access Control List)权限控制

zookeeper专门设计的ZAB协议

  1. 崩溃恢复：选举新的leader
  • 触发条件：leader崩溃；或者leader与过半follower失去联系
  • 选举新的leader，通知自己及集群内所有机器
  • 选举出的leader必然具有最大事务ID
  • follower同步leader数据，保证状态一致。同步完成的加入可用follower列表
  1. 消息广播：过半机器同意则提交
    • 基于具有FIFO特性的TCP协议来进行网络通信，保证消息接受与发送的顺序性。
    • leader为每个事务请求分配全局单调递增的唯一ID，保证顺序执行。
    • leader为每个follower分配一个单独队列，存放请求。
    • follower接到请求，先将其写入日志，再反馈给leader
    • leader接收到超过半数响应，则通知提交事务

选举算法

实际应用

1.发布/订阅：配置中心

信息特性：

  • 数据量通常比较小
  • 数据内容再运行时会发生动态变化
  • 集群中各机器共享，配置一致

两种模式：

  • pull：客户端与ZK建立心跳响应
  • push：在ZK注册watcher，接收节点事件更新

mark

2. 负载均衡

mark

mark

3.命名服务：生成全局唯一序列号

4.分布式协调/通知

5.集群管理

6.master选举：集群中选出某一台机器，来做一件事

  • 监控时间完成情况，通知其余机器
  • master机器宕机，可立即重新选举master

7.分布式锁

排它锁

共享锁

步骤：==会造成羊群效应，不断获取所有子节点==

  • 创建节点，获取/shared_lock节点下的所有子节点，并对改节点注册子节点变更的watcher监听。
  • 确定自己的节点序号在所有子节点中的顺序
  • 对于读请求：
    • 如果没有比自己序号小的子节点，或者所有比自己小的子节点都是读请求。那么表名，获取共享锁成功。
    • 如果比自己序号小的子节点中有写请求，那么就需要进入等待。
  • 对于写请求：
    • 如果自己不是序号最小的子节点，那么就需要进入等待。
  • 接收到watcher通知后，重复步骤【1】。

改进的共享锁

8.分布式队列

FIFO

Barrier：分布式屏障

  • 通过调用getData( )接口获取/queue_barrier节点的数据内容：10 即，达到10个调用
  • 通过调用getChildren( )接口获取/queue_barrier节点下的所有子节点，即获取队列中所有元素，同时注册对子节点列表变更的watcher见监听。
  • 统计子节点个数
  • 如果子节点不足10个，继续等待
  • 接收到watcher通知后，重复步骤2

Dubbo

使用zookeeper做为注册中心