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则是通过监听器，不需要不断重试
