原子性:不可分割
一致性:事务执行完,数据与业务预期一致
隔离性:事务与事务之间的隔离程度;
脏读:事务B读到事务A修改后,但提交失败的数据;
幻读:强调数据的增减,事务B两次读取数据的过程中事务A添加了数据,导致事务B两次读取到的数据不一致;
不可重复读:强调数据的修改,事务B两次读取数据的过程中事务A修改了数据;
读未提交:Read Uncommitted
读已提交:Read Committed
可重复读:Repeated Read
事务串行:Serialization
**准备阶段:**首先参与者执行事务操作,并返回执行结果给协调者;
**提交阶段:**协调者根据每个参与者执行结果通知参与者进行提交或回滚;
缺点:
1.同步阻塞,所有参与者都处于阻塞状态等待其他参与者响应;
2.单点问题:协调者单点故障,特别是在提交阶段故障时,将阻塞所有参与者;
3.数据一致性问题:协调者发送提交或回滚命令时,如发生网络异常导致部分参与者未收到指令,将使得系统数据不一致;
4.过于保守,一个节点失败,整个事务都会失败;
缺点:依然没有解决数据一致性问题
Try: 检测及预留资源
Confirm: 对业务系统做确认提交,
Cancel: 出现错误时回滚
1.节点完成操作后发送消息到本地消息表(本地事务确保一定能写成功);
2.本地消息表将消息转发到Kafka等消息队列中,转发成功则删除消息,否则继续转发;
3.其他节点从消息队列中读取消息,并执行;
优点:避免了分布式事务,能够实现最终一致性
缺点:需要异步,消息队列处理要求准确。
1.服务A发送半消息给Brock服务端,Brock返回半消息接收情况
2.服务A接收到返回结果,执行事务,并通知Brock执行Commit或Rollback
3.Rock若未接收到服务A事务的执行结果,一段时间后会主动询问A;
4.A检查事务执行状态,再次告知Rock执行结果;
5.Rock收到Commit后会正式将消息投递给其他节点;收到Rollback则不会投递消息,将消息存储三天后删除。
使用场景:
满足三个条件:1.资源共享;2.共享资源互斥;3.多任务环境
核心思想:1.获取锁;2.操作数据;3.释放锁
问题:实时检测或者等待的情况会浪费资源,获得锁的线程挂掉后没有释放锁容易死锁
解决思路:哨兵机制,启线程删除超时时间已过的已存在的锁;
引发新的问题:
1. 单个线程依然存在单点故障问题;
2. 多个线程需要保证线程通信,以及线程与库的通信延迟需要很低;
3. 多个线程之间的数据一致性问题;
4. 超时时间难以界定
核心思想:类似MySQL;
解决思路:用lua实现分布式锁,利用redis的有效期设置来解决死锁问题;
存在问题:有效期难以界定
特点:
1. 统一视图(数据一致);
2. 可以存储数据;
3. zookeeper目录分为:临时目录、持久目录、临时有序目录、持久有序目录;
4. 支持事件回调机制
思路:
1.利用临时有序目录对多个线程排序(类似于排队,排在第一个的先执行,每个线程给前一个注册一个回调事件);
2.每个节点执行完会自动删除本节点,并触发回调事件通知下一个节点开始执行;
优点:
1.节省资源,等待的节点不需要反复区确认是否可以执行;
2.通过临时有序节点和事件通知巧妙的解决了死锁问题
分布式集群下的定时任务。
常见使用场景:
- 任务存在互斥时,需要统一协调;
- 需要定时任务执行的反馈,如高可用、监控等;
- 统一管理和任务追踪,如执行任务的服务定位,负责人跟踪等;
常用框架:
1. quartz
2. xxl-job
3. LTS-admin
4. Elastic
5. TBS
本文地址:https://blog.csdn.net/weixin_43283363/article/details/107349556
如对本文有疑问, 点击进行留言回复!!
JavaScript 好题汇总分享(持续更新,看到好题就写)
XMLHttpRequest 2级 &&进度事件&&JSONP
使用递归原生实现拷贝&&最简单的方法实现深拷贝
网友评论