平面设计最好的网站,推广普通话的文字内容,现在互联网创业可以做哪些项目,网站建设都需要哪些材料分布式事务的问题可以分为两部分#xff1a;
并发控制 concurrency control原子提交 atomic commit
分布式事务问题的产生场景#xff1a;一份数据被分片存在多台服务器上#xff0c;那么每次事务处理都涉及到了多台机器。
可序列化#xff08;并发控制#xff09;
并发控制 concurrency control原子提交 atomic commit
分布式事务问题的产生场景一份数据被分片存在多台服务器上那么每次事务处理都涉及到了多台机器。
可序列化并发控制
定义了事务执行的正确性真正地并行执行事务获得真正的并行速度提升。 如果事务涉及到的数据不在同一台机器上那么可以同时在多台机器上读需要的数据。
原子提交处理在事务过程中服务器宕机的情况。如果事务执行过程中修改了部分值然后机器宕机需要能够具有故障恢复的能力。
一、并发控制
悲观并发控制。 冲突频繁比较适合避免频繁abort事务。乐观并发控制。事务最后的时候再检查有无其它的事务干扰如果有其它事务干扰那么必须Abort当前事务。
2PL Strongly 2PL规则1. 使用任何数据之前在执行任何数据的读写之前先获取锁。
事务必须持有任何已经获得的锁直到事务提交或abort这是严格2PL…
规则2的例子
不能在结束了对x的操作以后就立即释放锁比如说t1 ① ④ t2 ② ③ 这个锁无用了还是会导致事务交叉执行。
同时2PL也无法解决死锁简单例子如下 二、原子提交
原子提交协议需要保证事务的每一个部分都执行或者任何一个部分都不执行。All-or-nothing需要有一个计算机管理事务事务协调者Transaction Coordinator TC
2PC正常情况
如果B在回复prepare yes之前崩溃 TC会发现B没有回复yes也就不能commit因为它需要等待所有参与者回复yes
同时B如果发现自己故障可以主动发起abort。 有一种情况B故障内存中数据丢失所以再次接受prepare的时候完全不知道参与了该次事务因此直接发送No
如果B在发出prepare yes之后崩溃接下来极有可能发生的事情是事务协调者从所有的参与者获得了Yes的回复并将Commit消息发送给了A所以A实际上会执行事务分包给它的那一部分持久化存储结果并释放锁。这样的话为了确保All-or-Nothing原子性我们需要确保B在故障恢复之后仍然能完成事务分包给它的那一部分。在B故障的时候不知道事务是否能Commit因为它还没有收到Commit消息。但是B还是需要做好Commit的准备这要求参与者B在prepare时候必须持久化一些状态比如说记住所有的修改和事务持有的锁 这些其实都以log的形式存在然后才会回复yes这样如果B在发送完prepare yes后就崩溃那么恢复的时候可以查看自己的log。之后B最终收到了commit那么就可以完成它在事务中的那部分工作。
如果B在发出commit ok之后崩溃此时B已经完成修改数据以及持久化到磁盘上了故障重启之后不需要做任何事情。
如果事务协调者在发送commit之前崩溃那么没有一个参与者会commit事务
如果事务协调者在发送完一个或多个commit消息后崩溃要重发可以看Log来确定进展状况。既然已经发送了就不允许TC忘记相关的事务。这要求TC在发送任何commit之前都必须先将事务信息写入持久化存储中。重启后可以看到哪些事务执行了一般哪些事务commit哪些事务abort对于执行了一半的事务事务协调者会向所有的参与者重发Commit消息或者Abort消息以防在崩溃前没有向参与者发送这些消息。这也是为什么参与者需要准备好接收重复commit消息的原因。
TC发送prepare却没有收到所有回复
重发决定abort
发送commit却没有收到所有回复
block。 只能block因为其他的参与者可能已经回复ok并提交事务
TC获得了所有的ack此时TC可以删除Log中有关事务的信息参与者发送ack之后也可以删除log忘记这个事务…然后问题就来了这个ack丢失了咋办。那此时TC会再次发送commit消息参与者收到后发现自己不知道这个事务但因为这是一个commit消息说明自己一定是发送了ack后把log删除了因此此时参与者会再次发送ack。 三、总结
2PC的性能
由于有多轮消息非常慢由于存在Block很慢。
与Raft对比 Raft目标高可用而2PC并不是高可用的。原因在于Raft中的每台机器做一样的事情而2PC中的机器在做不一样的事情为了完成一个事务
Raft2PL实现高可用 分布式事务 原子提交
