分布式 知识点和方案 （详解在注释里面，图片加载需要时间）
2023-07-04 09:29:27 0 举报AI智能生成
知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。
作者其他创作
大纲/内容
分布式ID
SnowFlake 雪花算法
分布式理论
CAP 定理<br>
分区容错性：Partition tolerance<br>
一致性：Consistency<br>
可用性：Availability<br>
Consistency 和 Availability 的矛盾<br>
BASE 理论<br>
基本可用（BasicallyAvailable）<br>
软状态（SoftState）<br>
最终一致性（EventualConsistency）<br>
分布式事务的几种解决方案
分布式事务的实现方式<br>
刚性事务<br>
二阶提交 (2PC)<br>
核心原理
第一阶段<br>
第二阶段<br>
commit
Rollback<br>
缺陷
第一，在整个流程中，我们会发现各个资源管理器节点存在阻塞<br>
第二，仍然存在数据不一致的可能性<br>
第三，单点故障<br>
限制
它主要用在两个数据库之间<br>
三阶提交 (3PC)
核心原理
第一，CanCommit 阶段
第二，PreCommit 阶段<br>
第三，DoCommit 阶段
与2PC的区别
柔型事务<br>
事务补偿机制 (TCC)<br>
图示
核心<br>
缺点<br>
示例<br>
异常处理<br>
幂等控制：去重表<br>
空回滚：事务分支表+判空
防悬挂：事务控制记录表+判断
TCC特点<br>
不与特定的服务框架耦合<br>
支持多种事务日志持久化机制<br>
支持可配置recovery策略<br>
TCC与2PC（两阶段提交）区别<br>
TCC位于业务服务层，并非2pc在数据库的资源层<br>
2pc没有单独的准备阶段，而try兼顾资源操作与准备两方面<br>
TCC的try操作可以以业务确定粒度，即灵活选择资源的锁定粒度<br>
TCC开发成本高
可靠消息最终一致性事务<br>
利用消息中间件完成
需解决的问题<br>
1、本地事务与消息发送的原子性问题<br>
2、事务参与方接收消息的可靠性<br>
3、消息重复消费的问题
方案<br>
1、本地消息表方案<br>
核心思想
示例：注册送积分<br>
优缺点
优点<br>
缺点<br>
2、可靠消息服务<br>
生产者
消费者<br>
总结<br>
如何保证生产者服务对消息的可靠投递<br>
如何保证消费者服务器对消息的可靠接收<br>
3、分布式消息中间件（ RocketMQ）
两个阶段
prepare阶段<br>
确认阶段<br>
ACK机制<br>
流程<br>
使用<br>
问题
是否任何情况下MQ的事务性消息都可以保证双方的最终一致性？
示例：交易链路<br>
事务执行<br>
XA 规范<br>
图示<br>
事务协调者（Transaction Manager）<br>
资源管理器（Resource Manager）<br>
XA执行流程
XA的缺点<br>
性能不理想<br>
Seata实现<br>
Seata 中的 XA 模式<br>
实现<br>
XA 的几个问题<br>
数据锁定<br>
协议阻塞<br>
性能差<br>
与同为业务无侵入的 AT 模式比较<br>
Seata AT(TXC) 模式<br>
工作流程<br>
第一阶段<br>
第二阶段<br>
AT 模式二阶段提交
AT 模式二阶段回滚<br>
Seata AT模式优劣
亮点<br>
劣势
性能损耗<br>
补偿型事务模式的问题<br>
对比XA
AT 模式性能优势主要在于<br>
AT与 XA 的差别在什么地方？<br>
架构层次<br>
两阶段提交<br>
XA 的 2PC 过程<br>
AT 的 2PC 过程
分布式锁
mysql实现分布式可重入锁<br>
核心逻辑<br>
实现<br>
基于唯一索引（insert）实现<br>
实现方式<br>
简单实现方案<br>
完善实现方案<br>
获取锁<br>
超时检测和强制释放<br>
释放锁<br>
为什么要根据 id 而不是根据 name 释放锁？<br>
基于排他锁（for update）实现<br>
伪代码<br>
优缺点
乐观锁实现<br>
具体实现<br>
ABA问题<br>
缺点<br>
注意点
优缺点<br>
redis实现可重入分布式锁<br>
1、加锁Lua脚本<br>
脚本入参<br>
脚本内容<br>
脚本解读<br>
2、解锁Lua脚本<br>
脚本入参<br>
脚本内容
脚本解读<br>
Redission分布式锁
加锁-lock<br>
代码实现
lock()<br>
tryLockInnerAsync方法<br>
lock加锁的调用逻辑图
watchdog机制
scheduleExpirationRenewal
addThreadId()<br>
renewExpiration()
标号为 ④<br>
标号为 ①、②<br>
怎么判断是否有效呢？<br>
标号为 ③<br>
renewExpirationAsync<br>
会有什么异常呢？<br>
如果执行 renewExpirationAsync 方法的时候没有异常。这个时候的返回值就是 true 或者 false。
一旦触发看门狗机制，触发 renewExpiration 方法的线程就会变成定时任务的线程。
服务器宕机了？<br>
解锁-unlock
unlockAsync<br>
unlockInnerAsync<br>
图示<br>
cancelExpirationRenewal(threadId); 方法<br>
问题
如何实现超时自动释放锁？<br>
加锁失败之后如何实现阻塞等待加锁？<br>
如何实现阻塞等待一定时间还未加锁成功就放弃加锁<br>
超时放弃加锁的方法<br>
如何使用公平锁？<br>
如何实现读写锁<br>
Redisson是如何具体实现读写锁的呢？<br>
如何实现批量加锁(联锁)<br>
Redis分布式锁存在的问题<br>
举个例子<br>
如何实现RedLock算法<br>
客户端执行步骤<br>
RedLock算法的实现<br>
zk可重入分布式锁<br>
流程图
加锁源码解析<br>
acquire方法<br>
internalLock方法<br>
attemptLock方法
createsTheLock()<br>
internalLockLoop方法<br>
getsTheLock()<br>
如何实现可重入加锁<br>
加锁失败之后如何实现阻塞等待加锁<br>
流程图
如何实现阻塞等待一定时间还未加锁成功就放弃加锁<br>
如何实现公平锁<br>
如何实现读写锁<br>
加锁小结<br>
流程图<br>
释放锁release方法<br>
缺点<br>
ZK分布式锁和Redis分布式锁到底该选谁<br>
一致性哈希<br>
基础类型的Hash<br>
缺点
虚拟节点<br>
示例<br>
0 条评论
下一页
