09 | 事务：如何安全地实现多key操作？

老师分析得透彻，学习了，原来自己平时使用的事务过程中，无意间已经使用了串行化快照隔离级别，还请问一下事务性能相比put接口差异大吗

老师，有个问题就是 在原子性和持久性介绍当中，假如在WAF日志已经提交成功了，执行事务的时候发生了crash，这时候我理解的返回给client是失败的，那么当执行WAF重放日志的时候，该事务又成功了；换句话说，事务操作 返回给client 结果 的时机是什么时候呢，是写 WAF日志成功就返回呢，还是等待事务提交之后才返回呢

在数据库事务中，有各种各样的概念，比如脏读、脏写、不可重复读与读倾斜、幻读与写倾斜、更新丢失、快照隔离、可串行化快照隔离? 你知道它们的含义吗？ 脏读、脏写： 在读未提交的隔离级别的情况下，事务A执行过程中，事务A对数据资源进行了修改，事务B读取了事务A修改后且未提交的数据。A因为某些原因回滚了操作，B却使用了A对资源修改后的数据，进行了读写等操作。 不可重复读： 在读未提交、读提交的隔离级别情况下，事务B读取了两次数据资源，在这两次读取的过程中事务A修改了数据，导致事务B在这两次读取出来的数据不一致。这种在同一个事务中，前后两次读取的数据不一致的现象就是不可重复读。 幻读： 在可重复读得隔离级别情况下，事务B前后两次读取同一个范围的数据，在事务B两次读取的过程中事务A新增了数据，导致事务B后一次读取到前一次查询没有看到的行。 读倾斜、写倾斜： 读写倾斜是在数据分表不合理的情况下，对某个表的数据存在大量的读取写入的需求，分表不均衡不合理导致的。 更新丢失： 第一类丢失，在读未提交的隔离级别情况下，事务A和事务B都对数据进行更新，但是事务A由于某种原因事务回滚了，把已经提交的事务B的更新数据给覆盖了。这种现象就是第一类更新丢失。 第二类丢失，在可重复读的隔离级别情况下，跟第一类更新丢失有点类似，也是两个事务同时对数据进行更新，但是事务A的更新把已提交的事务B的更新数据给覆盖了。这种现象就是第二类更新丢失。 快照隔离： 每个事务都从一个数据库的快照中读数据，如果有些数据在当前事务开始之后，被其他事务改变了值，快照隔离能够保证当前事务无法看到这个新值。 可串行化快照隔离： 可串行化快照隔离是在快照隔离级别之上，支持串行化。 （讲得特别好，肯定花了特别多的心思跟时间，肯定掉了好多头发🐶，给老师点赞）

觉得可串行快照读讲的不是很详细还是我理解不到位。是每次执行事务都要先拿到读写锁还是在检测冲突重试才加读写锁？如果是前者根本没必要做冲突检测

关于事务txn，请问事务都是在leader执行的嘛？还是根据request中的动作决定？

老师，在etcd看来，写事件时，先获取数据，然后获取mvcc的读写锁，获取锁之后，再次读取数据，比较符合预期，最后更新数据。 看上去不像是乐观锁。 更像悲观锁

感觉可串行化的SSI有点牵强呢？看上去是用户手工来实现了SSi，而不是etcd自己实现了SSI。而且通过读代码，发现所有写操作在获取batchTx后都会LockInsideApply，是一个独占锁，所以看上去写操作是串行的，所以写事务应该也是串行的？我感觉是严格的串行执行写操作实现了可串行化。correct me if i'm wrong

请问etcd存在写-写并发冲突吗？因为并发写请求经过raft后，应该已经被整理成顺序执行的一个个条目，交给状态机串行地去apply了。这样在存储层还存在写-写并发冲突吗？

在快照串行化隔离的案例里面，有个问题想请教一下，首先冲突检测机制是在提交前进行检测的，那么意味着无论提交是否成功，大部分的节点都已经写入了raft log或者WAL，假设这次检测的结果是失败的（比如已经没有足够的钱进行转账），那么就不会提交了（给客户端的反馈也是此次转账失败）。 这个时候leader节点突然宕机，其他节点重新开始了选举，那些已经写入此次转账log的节点是有可能成为新的leader，在新的任期中，仍然会尝试提交这次事务，假设这次提交时已经有了足够的金额，则会导致提交成功。但是这次的提交成功对于客户端来说完全不感知，这样子就会导致用户发现自己的金额突然变少了，这个肯定是不符合预期的，老师可以解释一下这中间是不是有哪部分我的理解有问题呢

etcd事务可用在分布式事务吗？