《Zookeeper分布式过程协同技术详解》阅读小记

  • Zookeeper从文件系统API得到启发,提供一组简单的API,使得开发人员可以实现通用的协作任务,包括选举主节点管理组内成员关系管理元数据等。映射关系或者说协同数据称为元数据
  • ZK使用共享存储模型来实现应用间的协作和同步原语。
  • 主从架构的需求:①主节点选举:使得主节点可以给从节点分配任务;②崩溃检测:主节点必须具有检测从节点崩溃或失去连接的能力;③组成员关系管理:主节点必须具有知道哪一个从节点可以执行任务的能力;④元数据管理:主节点和从节点必须具有某种可靠的方式来保存分配状态和执行状态的能力。
  • ZK并不直接暴露原语,ZK暴露了由一小部分调用方法组成的类似文件系统的API,以便允许应用实现自己的原语。
    《Zookeeper分布式过程协同技术详解》阅读小记_第1张图片
  • Zookeeper的API:①create /path data:创建一个名为/path的znode节点,并包含数据data。②delete /path:删除名为/path的znode。③exists /path:检查是否存在名为/path的节点。④setData /path data:设置名为/path的znode的数据为data。⑤getData /path:返回名为/path节点的数据信息。⑥getChildren /path:返回所有/path节点的所有子节点列表。
  • 一个临时(ephemeral)znode在下面两种情况将会被删除:①当创建该znode的客户端的会话因超时或主动关闭而终止时。②当某个客户端(不一定是创建者)主动删除该节点时。
  • zookeeper使用通知机制来替代轮询机制,客户端对znode设置监视点,当znode发生变更时,客户端会收到一个通知,然后去zookeeper获取一个新值。监视点是单次触发,意味着每次变更之后客户端都要设置新的监视点。为了避免在设置监视点时znode发生变更导致客户端错过更新,客户端需要在设置监视点之前读取znode的状态
  • zookeeper可以定义不同类型的通知,依赖于设置监视点对应的通知类型。比如监控znode的数据变化,znode子节点的变化,znode的创建或删除。
  • 使用版本来阻止并行操作的不一致性。
  • “zookeeper集合”代表一个服务器设施,一个服务器设施可以由独立模式的一个服务器组成,也可以由仲裁模式的多个服务器组成。
  • 为了使可允许崩溃服务器数最优化,zookeeper集合内的服务器数量最好选择奇数
  • 客户端与服务建立的同一个会话,请求按照FIFO顺序执行,但同一个客户端的多个会话之间,不能保证顺序。
  • bin/zkServer.sh start [启动使用的配置文件路径]启动ZK服务器在后台运行。bin/zkServer.sh start-foreground [启动使用的配置文件路径]启动ZK服务器在前台运行。
  • 使用bin/zkServer.sh stop退出ZK服务器。
  • 会话状态:《Zookeeper分布式过程协同技术详解》阅读小记_第2张图片
  • ZK根据每一个更新建立的顺序来分配给事务标识符(zxid),当客户端因为超时重连时,只能连接观察到zxid更新的服务器。
  • 客户端使用create -e /path "节点数据"创建一个临时节点,-e参数是临时节点。不加参数就是持久性节点。
  • 客户端使用get /path获取节点数据。
  • stat /path true得到一个znode节点的属性,并允许我们在已经存在的znode节点上设置监视点。通过在路径后面加true来设置监视点。
  • zookeeper的API围绕zookeeper的句柄(handle)而创建,每个API调用都需要传递这个句柄,这个句柄代表与zookeeper之间的一个会话
  • 客户端断开连接会收到Disconnected事件,客户端成功连接(或重连)会收到SyncConnected事件。
  • 因为只有一个单独的线程处理所有回调调用,如果回调函数阻塞,所有后续回调调用都会被阻塞。所以尽量避免在回调函数中调用同步方法
  • 当连接丢失得到ConnectionLossException或者CONNECTIONLOSS编码,要检查系统当前状态,有可能已经创建节点成功,只是连接丢失了。
  • 客户端设置的每个监视点与会话关联,如果会话过期,等待中的监视点将会被删除。不过监视点可以跨越不同服务端的连接而保持,例如,当一个ZK客户端与一个ZK服务端的连接断开后连接到集合中的另一个服务端,客户端会发送未触发的监视点列表,服务端会检查已监视的znode节点是否在之前注册之后发生变化,如果发生变化,监视点的事件通知就会发送给客户端,否则会在新的服务端注册监视点。
  • 监视点有两种类型:数据监视点子节点监视点。创建/删除/设置一个znode节点的数据都会触发数据监视点,existsgetData这两个操作恶意设置数据监视点。只有getChildren操作可以设置子节点监视点,这种监视点只有在znode子节点创建或删除时才被触发。
  • Multiop可以原子性地执行多个Zookeeper的操作,即在multiop代码块中的所有操作要么全部成功,要么全部失败。
  • 客户端在本地缓存一个版本的数据,通过监视点监视数据的变化,当数据变化时收到通知进行本地缓存的更新。
  • 当zookeeper集群中的一个服务器故障时,连接到此服务器的客户端的Watcher对象就会收到Disconnected事件,并且所有进行中的请求都会收到ConnectionLossException异常。整个ZK服务本身依然正常,因为大部分的服务器仍然处于活动状态,所以客户端会快速与新的服务器重新建立会话。
  • 当客户端重连ZK服务器时,客户端会发送监视点列表和最后已知的zxid,服务器会接受这些监视点并检查znode节点的修改时间戳与这些监视点是否对应,如果任何已经监视的znode节点的修改时间戳晚于最后已知的zxid,服务器就会触发这个监视点。
  • 当我们对外部资源进行请求时,或我们在连接外部资源时,我们还需要提供一个隔离符号,如果外部资源已经接收到更高版本的隔离符号的请求或连接时,我们的请求或连接就会被拒绝。
  • Curator是Zookeeper的一个高层次封装库,核心目标是为你管理Zookeeper的相关操作,将连接管理的复杂操作部分隐藏起来。
  • 一个事务为一个单位,zk所有的变更处理需要以原子方式执行,比如setData,变更节点的数据信息+更新版本号,这两个操作要在同一个事务中运行,事务会被群首分配一个会话ID(zxid)。

你可能感兴趣的:(分布式)