第一部分:概念和基础
简介
基础概念
- 分布式系统定义:分布式系统是同时跨越多个物理主机,独立运行的多个软件组件组成的系统
- 分布式系统通信方式:
- 直接通过网络进行信息交换
- 读写某个共享存储
- zookeeper通过共享存储模型来实现应用间的协作和同步原语。
- 需要注意以下问题:
- 消息延迟:传输过程中可能发生任意延迟
- 处理器性能:操作系统的调度和超载也可能导致消息处理的任意延迟
- 时钟偏移
- 主-从架构需求
- 主节点选举
- 崩溃检测:主节点必须具有检测从节点崩溃或失去连接的能力
- 组成员关系管理:主节点必须具有知道哪一个节点可以执行任务的能力
元数据管理:主从节点必须具有通过某种可靠的方式来保存分配状态和执行状态的能力
难点:分布式系统中,如果一个主机或进程发生故障,其他主机继续运行,并会接管发生故障的进程,为了能够处理故障进程,这些仍在运行的进程必须能够检测到这个故障,无论是消息丢失或发生了时间偏移。
zookeeper基础
znode节点类型
- 持久节点(persistent)
- 临时节点(ephemeral):不能拥有子节点(未来可能支持)
- 持久有序节点(persistent_sequential)
- 临时有序节点(ephemeral_sequential)
临时节点被删除的情况:
- 客户端会话超时或主动关闭
- 主动删除该节点
有序节点的实现原理: ???(待解决)
znode节点的状态(stat)信息
zk状态的每一次改变,都对应着一个递增的transaction id
,该id称为zxid。
- czxid:节点创建时的zxid
- mzxid:节点最新一次更新发生的zxid
- ctime:节点创建时的时间戳
- mtime:节点最新一次更新发生时的时间戳
- dataVersion:节点数据的更新次数
- cversion:其子节点的更新次数
- aclversion:节点ACL的更新次数
- ephemeralOwner:是否为临时节点
- dataLength:节点数据的字节数
- numChildren:子节点个数
wathcer机制
- 替换轮询查询机制
- watcher是单次触发
- 根据对应的事件类型来处理通知事件
- 通知优先:先向client发送通知,再变更ZNode状态
问题:
- 事件丢失? 单次触发,那么在client收到通知与读取状态之间,可能发生其他事件,而这间隔发生的事件是无法捕获的,不过zookeeper保证客户端以全局的顺序来观察Zookeeper的状态。配合push-pull模式,将多个事件分配到一个通知上,能降低通知的数量。
版本
每一个znode都有一个版本号,它随着每次数据变化而自增。通过版本号实现乐观锁,方便多个客户端并发操作。
zookeeper仲裁
使用多数方案,就可以容许f个服务器的崩溃,这里f小于集合中服务器数量的一半。
- 问题:具体仲裁过程?
- 选举过程
会话
- zookeeper客户端库透明地转移一个会话到不同的服务器上
- 会话提供了顺序保障,这就意味着同一个会话中的请求会以FIFO顺序执行
- 会话的状态:CONNECTING、CONNECTED、CLOSED和NOT_CONNECTED
- 会话超时:如果经过时间t之后服务接收不到这个会话的任何消息,服务就会声明会话过期。而在客户端侧,如果经过t/3的时间未收到任何消息,客户端将向服务器发送心跳消息。在经过2t/3的时间后,Zookeeper客户端开始寻找其他的服务器,而此时它还有t/3的时间去寻找。
- 重新连接一个服务器:客户端已可连接服务器的zkid等信息来进行选择