分布式锁为什么要选择Zookeeper而不是Redis?看完这篇你就明白了

在分布式的应用中，为了防止单点故障，保障高可用，通常会采用主从结构，当主节点挂掉后，从节点可以代替主节点提供服务。

redis通过复制 + sentinel哨兵来实现主从模式。

zookeeper通过replicated mode复制模式来实现主从模式。

单从结构上看，redis和zookeeper都是主从架构，那zookeeper的优势是什么？为什么要选择zookeeper？难道只是因为zookeeper是目录结构，redis是k-v结构吗？

同步机制的不同

redis

redis在给从节点同步数据时，正常情况是增量同步，也就是主节点的数据修改语句（dml）会异步的同步给从节点。redis的数据同步没有保障数据一致性的机制，也就是说，一条dml在主节点执行成功时，不能保障其他从节点成功执行了这条数据，这就会造成一个问题，如果在数据没有同步到从节点时，主节点挂掉，就会产生数据丢失的情况。

zookeeper

zookeeper使用类paxos算法来保障数据的一致性。简单的讲，当一个dml语句发送给主节点时，zookeeper需要保证一半以上的节点接收到数据，才会返回成功。并且当主节点挂掉，从节点重新选举时，同步到最新的数据的节点会有优先选举权。

举个例子：

一个4节点zookeeper（a、b、c、d），a是主节点，当执行一个create语句成功时，至少有3台节点执行成功（一半以上），例如a、c、d成功。此时如果a节点挂了，b、c、d进行选举，由于c、d都执行成功了create语句，b没有执行，c、d的数据更加新，具有优先选举权，再根据名称排序，选择c做为主节点。在整个选举过程中，服务不可用，选举完成后，c节点和a节点数据一致，不会出现丢失的情况。

分布式锁

要实现分布式锁，需要满足一些要求：

• 只能有一个服务的一个线程能获取锁
• 一个持有锁的线程挂掉后，锁应该被释放，用来给其他线程用
• 一个持有锁的线程没执行完，锁不能释放
• 锁释放后，其他等待者可以继续争抢
• 管理锁的主节点（redis或zookeeper）挂了，重新选举后，不影响锁的持有情况

redis解决方案

问题1、问题2：使用“set key value ex seconds nx”语句获取锁并设置过期时间

问题3：另开一个监控线程，监控主线程执行情况，用来延长过期时间

问题4：等待线程定时检查锁的持有情况

问题5：暂无或者解决成本很高，需要自己实现类paxos的算法

zookeeper解决方案

通过创建临时节点可以解决问题1，2，3

watch机制可以解决问题4，并且相比定时检查，watch可以做到更高实时性

zookeeper的paxos同步机制保障了节点间数据一致性，即使主节点挂掉，也可以保障数据不丢，可以解决问题5

对比可以发现：

zookeeper的机制可以保证分布式锁实现业务代码简单，成本低。

redis如果要解决分布式锁的问题，对于一些复杂的情况，很难解决，成本较高。

以上就是分布式锁为什么要选择zookeeper而不是redis?看完这篇你就明白了的详细内容，更多关于分布式锁zookeeper redis的资料请关注其它相关文章！