《系统设计》,springcloud教程入门

本文介绍了Zookeeper的分布式锁实现原理,包括节点创建、监听器和会话超时等特性,避免了数据库唯一索引实现的锁问题。接着探讨了分布式事务,包括本地消息表和2PC(两阶段提交)的机制及其存在的问题。还讨论了CAP理论和BASE理论在一致性与可用性之间的权衡,以及在大型分布式系统中的应用。
摘要由CSDN通过智能技术生成

0000000000 ,它的下一个有序节点则为 /lock/node-0000000001 ,以此类推。

3. 监听器

为一个节点注册监听器,在节点状态发生改变时,会给客户端发送消息。

4. 分布式锁实现

创建一个锁目录 /lock ;

当一个客户端需要获取锁时,在 /lock 下创建临时的且有序的子节点;

客户端获取 /lock 下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是

则认为获得锁;否则监听自己的前一个子节点,获得子节点的变更通知后重复此步骤直至获得锁;

执行业务代码,完成后,删除对应的子节点。

5. 会话超时

如果一个已经获得锁的会话超时了,因为创建的是临时节点,所以该会话对应的临时节点会被删除,其它会话就可以

获得锁了。可以看到, Zookeeper 分布式锁不会出现数据库的唯一索引实现的分布式锁释放锁失败问题。

6. 羊群效应

一个节点未获得锁,只需要监听自己的前一个子节点,这是因为如果监听所有的子节点,那么任意一个子节点状态改

变,其它所有子节点都会收到通知(羊群效应),而我们只希望它的后一个子节点收到通知。

二、分布式事务

指事务的操作位于不同的节点上,需要保证事务的 ACID 特性。

例如在下单场景下,库存和订单如果不在同一个节点上,就涉及分布式事务。

本地消息表 本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并

且使用了消息队列来保证最终一致性。

1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息,本地事务能保证这个消息一

定会被写入本地消息表中。

2. 之后将本地消息表中的消息转发到 Kafka 等消息队列中,如果转发成功则将消息从本地消息表中删除,否则继

续重新转发。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值