1、分布式系统间的协调
A系统发消息到MQ,并在zk的某个节点注册监听器,B系统消费后修改zk那个节点的值,A立马就可以收到通知
2、分布式锁
节点尝试创建临时的znode,创建成功了就获取锁。别的节点尝试获取锁,却获取不到,就对这个锁注册一个监听器,当原来的节点释放锁后,新的节点就会感知到,然后尝试重新获取锁
3、注册中心、配置信息管理
kafka、storm、dubbo选用zk做一些元数据、配置信息的管理
4、HA高可用
重要进程做主备两个机器,主机器挂了就通过ZK切换到备用机器,备用机器就升级到主机器,原来的主机器恢复后就变成备用机器。比如hadoop,hdfs
二、比较下Redis和Zookeeper的分布式锁的区别1、Redis上锁
方案一:
系统A在redis中设置 set [key] [随机值1] NX PX 30000(NX:键不存在时才创建,PX:键的过期时间30000毫秒),这样系统B、C再设置时,由于已经设置过了,就返回true,所以只能A来运行。运行完后,释放锁(释放锁就是删除key)
如果设置之后,系统A运行时间过长,超过了30秒,那么这个key就会失效。此时系统B、C已经拿到这个锁了,要是这个时候让A直接删除就会有问题。所以要设置一个随机值,当redis发现系统A的随机值和现在的随机值不同,就不会让你删除
问题:
如果redis的主节点挂了,又由于同步是异步的,那么key可能还没复制到从节点,别的系统就可以又拿到锁了
方案二 RedLock算法(官方推荐):
2、基于临时顺序节点实现Zookeeper的分布式锁
3、两者区别
1)redis上锁很麻烦,RedLock算法还要搭建redis集群
2)redis获取不到锁,会不断尝试,比较消耗性能。zookeeper则是通过监听器,不需要不断重试
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)