东哥和系统设计开荒小分队的基地
当我们聊到分布式系统和单机程序不同之处时第一反应就是多台机器之间的网络问题。多台机器之间的网络连接给我们带来了很多便利，比如我们可以把多个不同地方的机器互联，再也不用担心单台机器带来的性能瓶颈等等。但同时也给我们带来了很多意想不到的问题，本文就来详细介绍为什么我们说网络是不可靠的。 简单Request可能遇到的问题 我们首先来看一下当一个节点发送一个request到另外一个节点，可能会遇到的问题（如下图所示）： 你的请求可能直接丢失了。（比如发送时网络突然断了） 你的请求可能会被堵塞在一个queue中，一段时间之后才会被发送。（比如网络负载很重或者接收端的直接过载等）...
我们已经在前文了解了数据库的弱隔离以及Serializable隔离的两种技术（串行执行和两阶段锁），每个人都想用Serializable隔离，毕竟它很好的处理了各种冲突。但很多时候又被逼无奈选择弱隔离，原因也很简单，Serializable隔离好虽然好，但是性能消耗太大了，选择它就意味着选择了低的性能。所以人们一直在感叹假如有一种方法能做到Serializable隔离，性能损耗又不大的话就好了。皇天终归不负有心人，一个新的算法横空出世，它就是Serializable Snapshot isolation，简称SSI，它的优点就是能够牺牲很小的性能达到Serializable隔离的效果，这个算法是2008才出现的，不过已经被运用在PostgreSQL的版本9.1和FoundationDB中了。本文就来详细介绍一下这一最新的技术。 悲观和乐观的同步控制 我们在《Transaction...
我们在前面的《Transaction Serializable隔离之串行执行》中介绍了Serializable隔离的第一个实现方法：串行执行。本文来介绍第二个实现方法：两阶段锁（Two-Phase Locking）。这个方法也是一个由古到今一直流行的方法，需要注意的是他和我们通常说的两阶段提交（Two-Phase Commit）是完全不同的两个概念，我们会在后面的文章中再详细介绍两阶段提交的概念。 我们都知道锁的作用：就是有transaction想同时写一个object，这个锁可以保证两个写中的一个必须等待另外一个完成。两阶段锁也是类似的，只是说它更加强一点。假如一个object没有人在写，那么多个读可以同时进行。但是只要有人想要写这个object，那么就有下面这样的限制：...
我们在前面几篇Transaction弱隔离相关的文章中介绍了读提交，snapshot隔离，write skew和Phantoms。但这些总给我们一种感觉就是他们只能解决部分问题，而且使用起来很不方便，需要注意很多方面。那么有没有什么好的办法来一次性解决所有问题呢？答案是有的，那就是我们今天要介绍的史上最强，超级无敌的Serializable隔离。 Serializable隔离一般会认为是最强的隔离级别。它保证了哪怕有多个transaction并行执行，它的结果和串行执行的结果是一样的。而这个是由数据库本身来保证的，也就是说数据库处理了所有的冲突情况。 既然Serializable隔离这么强，那么大家都用它就好了啊，我们为什么还需要考虑别的呢？显然世界上不会有免费的午餐，想要得到强大的力量，必然就要付出相应的代价。要想了解这个代价是什么，我们首先要来看看一般来说都是怎么实现Serializable隔离的，大概的方法有下面这些： 真正的串行执行所有的transaction。...
我们在前面的《Transaction弱隔离之读提交的介绍和实现》和《Transaction弱隔离之更新的丢失》中分别介绍了脏写和更新丢失。他们都是有两个写同时发生，从而产生了冲突。那么对于这种情况，我们必然需要进行保护和处理，可以是数据库来自动处理也可以是手动的加一些保护比如锁或者原子写操作等。然而上面提到的两种写冲突就是全部了吗？现实世界显然更加残酷，本文就来具体看看别的冲突的例子。 如下图所示，假设你正在维护一个医院的值班系统，这个系统一般来说会安排几个医生一起来值班，当然它的最低要求是必须有一个医生值班。所以说，当轮到你值班的时候，假如还有别的医生在值班，你就可以从这个系统中请假。请假的操作也很简单，就是假如系统中显示有两个及以上的医生在值班，那么就允许你更新自己的状态成不值班。 现在我们假设Alice和Bob突然同时有事，一个身体不舒服，一个想去和女朋友约会，他们在下班之前的那一刻同时准备到系统中来请假，并且同时执行了请假的操作。然后就有了两个transaction同时执行，他们都是读的snapshot的内容，所以在更新的之前on call count都是大于等于2的，然后他们同时更新了他们自己的状态到请假（on_call...
我们在前文《Transaction弱隔离之读提交的介绍和实现》和《Snapshot的隔离和Repeatable的读》中介绍了read commit和snapshot隔离。这两篇文章其实更多地讨论的是当有写发生的时候如何进行读，除了脏写之外没有更多地讨论如何处理两个写同时发生的情况。其实当有两个写同时发生的时候还会有很多问题需要处理，其中最常见的就是两个写有冲突，这个时候就会发生更新丢失的问题。 我们举个例子，比如一个transaction先从数据库读一个数据，然后修改这个值，再把它写回数据库（读-修改-写的模式）。当有两个transaction同时发生这件事的时候，其中一个transaction的写就会丢失。这种pattern其实在现实中很常见的： 比如说你需要增加一个计数器或者更新账户的余额，需要先读出原来的值，计算出新的值，然后更新。 更新一个复杂值的一个部分，比如说你在JSON文档里面加一个元素，需要首先解析这个文档，做修改，然后写回去。...
我们在上文的《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的操作...
我们在上文《Partition的基本概念和实现介绍》中主要分析的是key-value格式的数据，也就是说所有的partition都是基于primary key来决定如何route读写请求的。而实际的系统可能不是只有primary key这么简单，它可能会有第二个index，那么如何处理这种有第二个index数据的partition呢？一般来说有两种常见的方法：一种是基于文档的 document-based partition，另外一种是term-base的partition。...
Follow:
More
Recent Comments