首页天道酬勤实现分布式锁,分布式锁框架

实现分布式锁,分布式锁框架

张世龙 05-03 21:12 51次浏览

1.Zookeeper分布式锁定分布式锁定要求:独占性

zk的/path满足独占性,在/path中添加watch,失效后通知其他节点

Zookeeper非公平锁定/公平锁定/共享锁定Leader在选举分布式场景中的应用Spring Cloud Zookeeper注册中心实战

Zookeeper分布式锁定原理

公平锁:上述导致羊群效应的实现方式,在并发问题严重的情况下,性能会下降。 主要原因是所有连接都监听同一节点,服务器检测到删除事件时通知所有连接,所有连接同时接收事件,并再次发生冲突。 这种锁定方式是不公平锁定的具体实现。 怎么避免呢? 看看下面的方式吧。

通过添加prefix,幽灵节点的问题(节点已创建,但客户端不知道)这样的临时顺序节点可以避免同时多个节点冲突的锁定,缓解服务端的压力。 该实现方式对所有锁定请求进行排队锁定,是公平锁定的具体实现。

前面两种锁定方式有共同的特质。 也就是说,互斥锁。 同一时间只能占用一个要求。 大量并发会导致性能急剧下降。 所有请求都必须被锁定。 那真的所有要求都需要锁定吗? 答案是否定的。 例如,如果没有对数据进行任何修改,就不需要进行锁定,但是读数据的请求还没有完成,这时写请求来了怎么办? 已经有人在读数据了。 这个时候不能写数据。 否则,数据是不正确的。 在释放所有前一个读锁定之前,无法执行写请求。 因此,必须标记此读取请求(读取锁定),以指示写入请求此时无法修改数据。 否则数据不一致。 如果已经有人写了数据,也不允许另一个请求写数据。 这样做还会导致数据不一致。 因此,所有写入请求都必须具有写入锁定,以避免同时执行对共享数据的写入操作。

举一个例子

1、读写不同时一致

2、双写不一致时

Zookeeper共享锁的实现原理

2 .注册中心(可同时耐受数万个)注册中心场景分析:

在分布式服务体系结构相对简单的情况下,我们的服务可能需要这样的当前订单服务调用外部服务的用户服务。 对于外部服务依赖,直接放在我们的服务配置文件中,在服务调用关系比较简单的情况下完全可以。 随着服务的扩展,用户服务可能需要执行以下群集部署:

如果系统调用不那么复杂,可以通过配置管理,然后实现简单的客户端负载平衡,但随着业务的发展,服务模块更加细分,业务更加复杂,简单的配置文件管理难以维护当然,可以在前面添加服务代理,例如将nginx作为反向代理,如下所示

如果我们是下面的场景呢?

服务不再像A-B、B-C那么简单,而是错综复杂的小服务调用

此时,我们可以利用Zookeeper的基本特性实现一个注册中心。 什么是注册中心? 顾名思义,就是让Zookeeper注册很多服务。 什么是注册? 注册是指在Zookeeper节点上写入自己的服务信息,例如IP、端口和更具体的服务信息。 这样就可以直接获得所需的服务,在这种情况下,可以定义统一的名称,如用户服务。 所有用户服务在启动时都在名为User-Service的节点下创建子节点(临时节点)。 该子节点可以是唯一的,并且依赖于表示每个服务实例的唯一标识符的用户服务,例如Order-Service,通过父节点User-Service将所有User-Service子节点节点获取并获取子节点的数据后,Order-Service将对其进行缓存,并拦截客户端上的此用户- service目录,以便即使新节点加入或退出,Order-Service也是如此这将使Order-Service重新获取所有子节点并更新数据。 此用户服务的子节点类型为临时节点。 正如第一课中所述,在Zookeeper中,临时节点的生命周期与会话相关联。 SESSION超时后,相应的节点将被删除,删除后,Zookeeper将通知监听该节点父节点的客户端,并允许相应的客户端更新本地缓存。 新服务加入后,也会通知相应的客户端,并刷新本地缓存。 要实现此目标,客户端必须通过重复注册拦截父节点。 这样就实现了服务的自动注册和自动退出。

Spring Cloud生态也提供了Zookeeper注册中心的实现。 这个项目叫Spring Cloud Zookeeper,进行实战。

项目说明:

为了简化需求,我们用两个服务来说明。 实际使用时,可以举出1、3

用户中心:用户服务

产品中心:产品服务

当用户调用产品服务并实现客户端负载平衡时,产品服务将自动加入群集并自动终止服务。

项目地址:https://github.com/Chen ruoyu 0319/zookeeper-register-center.git

分布式锁和一般锁有什么区别,redis分布式锁的原理