CP机制
文件系统+监听机制
)统一命名服务
、分布式配置管理
、分布式消息队列、分布式锁
、分布式协调
等功能问题
:使用文件系统模型的原因
表达数据之间的层次
关系不同的应用分配独立的命名空间
注意:
问题:
Zookeeper是强一致性吗
基本可用:在分布式系统出现故障的情况下,允许损失一定的可用性来保证基本可用,比如通过服务降级、页面降级等措施
软状态: 在分布式系统允许出现不影响系统可用性的写数据延迟
最终一致性: 数据备份节点经过一段时间达到一致性
引申
Base理论就是对于CAP中C和A的权衡,我们无法保证强一致,但是能通过适当的方式保证最终一致性
弱一致性
: 系统中对于某数据的写操作后,无法保证在不同时间段读取到一致的数据
最终一致性
: 系统在保证没有新的写操作的情况下,读取到的数据是一致的最新数据
顺序一致性
: 任何一次读都能读到最近一次写的数据,并且新的写入是建立在已经达成同步的基础上的
extendedTypesEnabled=true
开启,ttl不能用于临时节点,而且不稳定
客户端注册监听它关心的任意节点,或者目录节点以及递归子节点
如果注册了某个节点监听,那么当这个节点被删除或者被修改时,对应的客户端将被通知
如果注册的是对某个目录的监听,那么当这个目录有子节点被创建或者有子节点被删除,对应的客户端将被通知
如果注册的是对某个目录的递归子节点进行监听,那么当这个目录下面的任意子节点有目录结构的变化(有子节点被创建或被删除)或者根节点有数据变化时,对应的客户端将被通知
简化
: 监测是一次性的,每次触发之后都需要重新进行注册,如果注册了监听,任何写操作都会通知客户端一次
注意:
所有通知都是一次性的,即无论是对节点还是对目录进行的监听,一旦触发,对应的监听立即被移除。递归子节点,监听是对所有子节点,所以每个子节点下面的事件同样只会被触发一次
注意:
zk中的watch机制,必须客户端先去服务端注册监听,这样事件发送才会触发监听,通知给客户端分布式配置中心
分布式注册中心
分布式锁
分布式队列
分布式屏障
发布/订阅(常用于配置中心)
数据发布/订阅的一个常见的场景是配置中心,发布者把数据发布到zk的一个或一系列的节点上,供订阅者进行数据订阅,达到动态获取数据的目的
配置中心一般有几个特点
zk采用的是推拉结合的方式
负载均衡: 在zk中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求
统一命令服务
在分布式环境下,经常需要对应用/服务进行统一命名,便于识别,例如:ip不容易记住,而域名容易记住