[mongodb文档]分布式一致性

[mongodb文档]分布式一致性（一）[1]一致性模型对于一个分布式数据库来说是至关重要的。这里我们将专门一个专题的形式来讲解一些主题：例如：针对一些具体的应用场景应该使用什么样的模型。首先从一些最基本的理论知识开始。

CAP

CAP理论指出任何一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availibility）和分区容错性性（Partition Tolerance）这三个要求，最多只能同时满足其中的两个。同时，在一个分布式系统中，由于硬件或其他未知原因，不可避免的会出现网络分区的情况，因此在分布式系统的设计上必须考虑到对这种情况进行容错。于是，CAP理论其实决定了一个分布式系统的设计最终必然会聚焦于如何在数据一致性和高可用性上找到一个平衡点。

解决方案

通常我们会有两种各类型的系统架构，一种是系统能够实现强一致性的，我们将这种方案成为C方案。另一种则是牺牲一些一致性，但是能够保证高可用的方案，我们称之为A方案。我们结合一些真实的工业实现来加深对这两类架构的理解。Amazon Dynamo是一个分布式存储系统，他利用一致性哈希来完成数据的分区。Dynamo能够做到最终一致性，因此在过程中会被脏（旧）数据，属于A类架构。Apache CouchDB是一个面向文档的数据库管理系统，其最显著的特性是支持多主复制，属于A类架构，同样能够做到最终一致性。MongoDB提供了一种自动分片（Auto-Sharding）的机制来是实现系统的水平扩展，同时在某一个时间点上，存在一个Master角色的机器，属于C类架构，因此和传统的关系型数据库一样，都能够保证强一致性。

关键的问题是，如何保证写可用，而不是读

As the replication isasynchronous, this data is eventually consistent, so this result is notsurprising ― we are now in the A class of systems. However, almost all designs,even from the C class, can add on asynchronous read capabilities easy. Thus,the critical design decisions are around write availability.如今，绝大部分的数据库系统，都能够很容易的构建一个由任意数量Slave组成的分布式数据库集群，其通过异步复制来实现数据的同步。如果在出现网络隔离故障导致网络分区的时候，依然能够访问本地Slave机器上的数据。同时，由于采用异步复制，因此能够保证数据的最终一致性――似乎这就一种典型的A类架构了。另一方面，几乎在所有的架构设计中，我们都能够添加一些只读角色，这些角色通过异步复制来获取集群的数据，以提高集群对外整体的数据读取能力，而要提高写能力则往往并不那么容易。因此，在平常的架构设计过程中，都是围绕如何提高写性能来展开的。

如何权衡

・ even load distribution is easier ineventually consistent systems・ multi-data center support is easierin eventually consistent systems・ some problems are not solvable witheventually consistent systems・ code is sometimes simpler to write instrongly consistent systems 我们将在稍后的几篇文章中更深入的讲解这些方案的利弊。

[mongodb文档]分布式一致性（二）最终一致性模型[2]在上一篇中，我们已经初略的介绍了A类和类架构。对于A类架构，我们需要牺牲一致性去提高系统的整体可用性。当然，这并不代表这类系统完全不考虑分布式一致性问题，只是说在一定程度上调整一致性级别，即并不要求强一致性。Amazon普及了最终一致性的概念，并对其进行了一个清晰的定义：如果一个存储系统能够保证在没有新的更新请求的情况下，最终所有的客户端都能够访问到最新的数据，那么这个系统就符合最终一致性的要求。最终一致性的概念其实并不是一个什么特别新的东西，但Amazon的伟大之处在于他第一次将这样一些晦涩难于理解的分布式理论，转化成了一个形式化的，已于推广的定义。最终一致性的典型例子有：DNS系统。
主备异步复制的关系型数据库（当然，MongoDB也是类似的）。
分布式缓存。
在很多分布式系统中，如果只有一个Master来负责处理所有写请求的话，那么是能够做到最终一致性的。但是如果系统中存在多个可写的Master的话，那么处理逻辑将会变得非常复杂。Amazon Dynamo就是这样一个存在多个Master写入的系统。上面提到的3个场景都是只有一个Master的。另外，消息队列也是解决分布式最终一致性问题比较常见的方案。Forms of ConsistencyLet’slook at a particular example. Consider a system using MongoDB in thefollowing configuration:

[1] http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1 [2] http://blog.mongodb.org/post/498145601/on-distributed-consistency-part-2-some-eventual