MySQL的事务介绍
本周我们继续由Junzhi给我们带来MySQL系列讲座的第三讲，事务的介绍，相关的总结如下： Slides Junzhi使用的slides。 MySQL系列讲座第一讲总结：MySQL DB...
Tagged: transaction
Transaction Serializable隔离之串行执行
我们在前面几篇Transaction弱隔离相关的文章中介绍了读提交，snapshot隔离，write skew和Phantoms。但这些总给我们一种感觉就是他们只能解决部分问题，而且使用起来很不方便，需要注意很多方面。那么有没有什么好的办法来一次性解决所有问题呢？答案是有的，那就是我们今天要介绍的史上最强，超级无敌的Serializable隔离。 Serializable隔离一般会认为是最强的隔离级别。它保证了哪怕有多个transaction并行执行，它的结果和串行执行的结果是一样的。而这个是由数据库本身来保证的，也就是说数据库处理了所有的冲突情况。 既然Serializable隔离这么强，那么大家都用它就好了啊，我们为什么还需要考虑别的呢？显然世界上不会有免费的午餐，想要得到强大的力量，必然就要付出相应的代价。要想了解这个代价是什么，我们首先要来看看一般来说都是怎么实现Serializable隔离的，大概的方法有下面这些： 真正的串行执行所有的transaction。...
Transaction弱隔离之更新的丢失
我们在前文《Transaction弱隔离之读提交的介绍和实现》和《Snapshot的隔离和Repeatable的读》中介绍了read commit和snapshot隔离。这两篇文章其实更多地讨论的是当有写发生的时候如何进行读，除了脏写之外没有更多地讨论如何处理两个写同时发生的情况。其实当有两个写同时发生的时候还会有很多问题需要处理，其中最常见的就是两个写有冲突，这个时候就会发生更新丢失的问题。 我们举个例子，比如一个transaction先从数据库读一个数据，然后修改这个值，再把它写回数据库（读-修改-写的模式）。当有两个transaction同时发生这件事的时候，其中一个transaction的写就会丢失。这种pattern其实在现实中很常见的： 比如说你需要增加一个计数器或者更新账户的余额，需要先读出原来的值，计算出新的值，然后更新。 更新一个复杂值的一个部分，比如说你在JSON文档里面加一个元素，需要首先解析这个文档，做修改，然后写回去。...
Snapshot的隔离和Repeatable的读
我们在上文的《Transaction弱隔离之读提交的介绍和实现》中详细介绍了读提交，总得来说它是一个很好的保证，但是有了它是否就足够了？答案是否定的，即使有了读保证，我们仍然会有问题，而这就是本文准备详细介绍的内容 。 我们首先来看下面这个图： 我们假设Alice有1000块存在银行里，分别在两个account里面，开始的时候每个账户里面放了500块。然后Alice开始查询两个账户一共多少钱，这个查询是一个transaction，它开始查到账户1里面有500，然后这个时候发生了一个交易，就是把账户2的钱转了100到了账户1. 在整个第二个transaction（转账的transaction，包含两个操作，一个是把账户1加100，一个是把账户2减少100）完成后，之前查询的transaction的第二个查账户2的操作才到了，所以它看到的账户2的数值是400，这就导致了Alice看到的账户总额变成了900而不是1000。这个过程中，并没有脏读，因为第二个400的读是在transaction完成之后才读的，所以完全符合之前读提交，但仍然还是有了问题。...
Transaction的基本概念和介绍
我们已经知道了分布式系统中有很多问题，比如说我们正在读的数据也许正在被别人修改，系统有可能在我们执行一系列操作的中途crash，多个同时发生的写操作可能相互覆盖等等。我们总归需要一个好的方法来解决这个问题。而Transaction的产生就是为了解决这些问题，所谓的transaction就是应用程序把一系列操作组合成一个逻辑单元， 这个单元可以认为是一个原子操作，要么就全部成功，要么就全部失败。有了Transaction的概念之后，错误的处理就变得方便了很多。 单Object和多Object操作 在我们详细介绍之前，请大家一起先来回顾一下ACID的概念，你可以在我之前的这篇文章《SQL和NoSQL的分析》中找到详细的介绍，这里不再复述。 多Object的操作...
Recent Comments