一开始，我是带着如下问题来学zookeeper：
- 像Mysql，Hbase这类的数据库已经实现了高可用，为什么我们还要用zookeeper呢？
（比方说，为什么我们一般用zookeeper来实现主从，选举，分布式配置中心？） - 分布式锁有很多实现方案，例如使用Redis或者Zookeeper，那么他们的实现有何区别？
- Zookeeper有哪些缺点
问题一
关于第一个问题
像Mysql，Hbase这类的数据库已经实现了高可用，为什么我们还要用Zookeeper呢？
（比方说，为什么我们一般用Zookeeper来实现主从，选举，分布式配置中心？）
我是这样理解的，像Mysql，HBase这类的数据库，都通过了某种机制实现了高可用（例如Mysql通过主备设计实现高可用），完全是可以用他们来代替Zookeeper。
比如我们用Mysql实现一套选举机制：
- 首先，我们建个表proposal
create table proposal(
INT id AUTO_INCREMENT comment='自增id',
varchar(30) uuid NOT NULL comment='全局唯一ID',
INT heart_beat comment='上次心跳时间',
INT type comment='1为参选 2为上任'
)
- 服务初始化的时候，我们各个服务器往这个表里INSERT(其中type为1)。
- 由于INSERT本身是有序的，那么Id最小的那位就成功当选。是不是很简单。
- 当选服务器(A)往表里面INSERT一条type=2的数据，表示已经上任。
4.1 如果当选服务器(A)挂了，别的服务器通过观察A的heart_beat能计算出A是否挂了。
4.2 服务器A的插入操作也应该优化，使用INSERT IF NOT EXIST
4.3 当有服务器发现A关掉后，马上开始下一次选举，重新从步骤2开始 - 服务器A定期更新自己当选记录的heart_beat,这样一旦他挂掉，别的服务器也能马上发现，那么又开始下一次选举。
从上述步骤我们可以看出，使用mysql实现选举貌似是可行的。但我也只是初略的实现了步骤，并不能保证选举的可靠性。比如步骤4.1中，别的服务通过时间戳的方式计算是否可靠。要知道分布式环境下是没有可靠的时钟系统的，因此补救的方法可能是靠延长过期时间，或者让Mysql来判断。其次，如上实现采用了心跳和轮训机制，性能上也存在一定的问题。
总之，我想表达的是，分布式算法可能并不复杂，但是有很多坑。即使我们使用可靠的数据库，我们的实现依然可能存在很多问题。而这种问题又是极难在普通测试中发现的。与其自己维护一套定时炸弹，不如用开源软件，除了问题还能甩锅，你说对不。
其次，Zookeeper采用了专为分布式业务设计的一套API，可以说，比起用Mysql自己实现分布式业务，用Zookeeper更好用，更易扩展。
结论
可以，但不建议。
问题二
分布式锁有很多实现方案，例如使用Redis或者Zookeeper，那么他们的实现有何区别？
用Redis如何实现分布式锁
这可是热门的面试题，答案无非是
- 用SetNX,Lua脚本保证锁的原子性
- 设置一个过期时间保证锁，保证锁一定会被释放
当然，使用上述实现会出现一些问题：
- 过期时间设置短了，任务还没执行完锁就给释放掉了。
- 过期时间设置长了，服务挂了又得等很长时间。
- 等待锁的服务会一直轮询，存在一定性能问题
- 主从切换的时候，可能会有数据丢失。（当然你也可以设置每次数据更新都等从节点写入了再回复，但是那样又挺影响性能）
上述问题，其中1，2可以通过添加一个WatchDog，不停去更新过期时间。3也可以通过Redis的watch功能来实现。
唯一棘手的也就是问题4，这也是Redis分布式锁的核心问题。
Zookeeper实现分布式锁
Zookeeper实现分布式锁就更为简单，这是写在它基因里的东西。
使用Persitent节点，或者使用Ephemeral节点。
其中使用Persitent简单（其实也没简单多少），但是会导致羊群问题（由于太多Client Watch了这个Node，导致一旦更新，需要同步很多次，产生流量高峰）。
而使用Ephemeral可以有效解决这个问题。
但由于Zookeeper本质是CP(Consistency & Partition tolerance)的分布式架构。那么如果出现了，半数服务崩溃或者网络分区的问题，会导致Zookeeper不可用，从而导致分布式锁不可用。
区别
Redis实现的分布式锁与Zookeeper实现的分布式锁，本质的区别就在于：
- Redis是AP架构
- Zookeeper是CP架构
我们都知道，没有一种分布式架构能同时保证CAP，那么
- 需要保证锁的完全一致性时，我们选择Zookeeper
- 需要保证锁的高可用性，并且能容忍锁在极端条件下失效时，我们选择Redis
问题三
Zookeeper有哪些缺点
没有一个框架是完美的，首先我们先谈谈Zookeeper的优点：
- 很好的抽象了分布式业务需要的原语，是的我们在使用时，能有很大的想象空间
- 历经时间证明的分布式服务，用着安心
- 基于内存的存储设计，并发也不算太低
其实硬要我说出Zookeeper有什么缺点，我还真说不出来。不过最近阅读了一篇阿里大牛的文章，还是搜获颇丰。
阿里巴巴为什么不用 ZooKeeper 做服务发现？
这篇文章主要讲解了，阿里在通过十年的技术更迭之后，为何在服务发现这块放弃使用Zookeeper的。
- 阿里服务发现规模太大，Zookeeper存在单点问题。(😂,阿里爸爸就是不一样，这是小公司无法想象的)
- Zookeeper因为其CP的性质，无法保证服务的高可用性，及出现网络分区问题时，本来同机房还是能正常完成服务调用的，但是由于Zookeeper的不可用直接影响来服务调用。(不过这点应该是可以使用客户端缓存来解决的)
- ZAB协议需要记录所有的修改数据，但是在服务发现领域，很多旧数据是不需要存盘的（如服务健康状态）。而如果不记录健康数据，使用Zookeeper的心跳机制，又不够用。
- Zookeeper太过复杂，需要专门的Zookeeper专家才能维护大的Zookeeper集群(自己实现的难道就不复杂？)
- Zookeeper有太多坑，比如ConnectionLossException和SessionExpiredException
5.1 ConnectionLossException代表和Zookeeper连接丢失，可能是网络出问题了，也有可能是master挂了，亦有可能是客户端负载太高了阻塞了太久。这种情况下，造成的问题是，客户端不知道自己发送的请求是否成功，同时也不知道ConnectionLoss期间watch的数据是否发生过变化，这就需要我们手动去同步Zookeeper和客户端之间的状态。（不过对于Watch造成的问题我是存疑的，毕竟Zookeeper每一个操作都是有一个ZXID的，那么从新连接时，难道不能通过这个ZXID来恢复状态？）
5.2 这种情况更惨，这代表连接不但丢失了，等你连上Zookeeper都以为你之前死了。把你的所有临时节点都给删了。这种情况下，你不仅需要执行5.1的同步操作，还要想方设法把你丢失的临时节点的逻辑给补上(想想就很麻烦 = =)
总结
Zookeeper并不完美，但是它是一款成熟的分布式问题的解决方案。
它也许不能解决你的全部问题，但在绝大多数情况下，它应该是我们的第一选择。
其实，当个动物管理员也挺好🐒。
