Monthly Archive: June 2021
我们在上文的《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完成之后才读的，所以完全符合之前读提交，但仍然还是有了问题。...
我们在上文《Transactions的基本概念和介绍》中提到，transaction的一个作用就是可以做到隔离。比如说当一个translation在写一个数据的同时，如果有另外一个transaction在同时读或写，就有可能会有问题。而且这种问题很难发现和debug，所以一般来说这种transaction级别的隔离都是由数据库本身来保证的，理论上来说这样应用的开发者就不需要来操心具体的细节了。可惜理想很丰满，现实却很骨感。很多时候数据库本身因为各种原因（性能等因素），它提供的不是严格的隔离，而是一种弱隔离，简单来说就是能保证一些同时读写的操作，但是有一些却不能保证。这样一来开发者就有点懵了，我究竟该何去何从呢？本文就来详细给大家介绍一下常见的transaction弱隔离，相信了解了这些之后，你再去开发应用就会游刃有余了。 读提交（Read Committed） 所谓的读提交其实是最基本的一种transaction隔离，它做到了以下两点保证： 当读数据库的时候，只会读到已经提交的数据。（没有脏读）...
我们已经知道了分布式系统中有很多问题，比如说我们正在读的数据也许正在被别人修改，系统有可能在我们执行一系列操作的中途crash，多个同时发生的写操作可能相互覆盖等等。我们总归需要一个好的方法来解决这个问题。而Transaction的产生就是为了解决这些问题，所谓的transaction就是应用程序把一系列操作组合成一个逻辑单元， 这个单元可以认为是一个原子操作，要么就全部成功，要么就全部失败。有了Transaction的概念之后，错误的处理就变得方便了很多。 单Object和多Object操作 在我们详细介绍之前，请大家一起先来回顾一下ACID的概念，你可以在我之前的这篇文章《SQL和NoSQL的分析》中找到详细的介绍，这里不再复述。 多Object的操作...
Recent Comments