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

时间:2022-01-12 05:11:56

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

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的资料请关注服务器之家其它相关文章!

原文链接:https://www.cnblogs.com/chenkeyu/p/14793627.html