概念和背景

简单来说，指的就是在存储系统中，客户端对数据的读写行为都是可以预期、符合一定规则的。这里有两个值得注意的方面：

这里面隐含了一个事情，就是说，为什么要有数据备份呢？

服务为了高可用，就要部署多个节点；数据为了高可用，就要存放多个备份。这里的数据，既包括数据本身，又包括数据的读写服务，这是因为：

一致性模型

强一致性（Strong Consistency）：强一致性要求任意时间下，读操作总是能取得最近一次写操作写入的数据。
弱一致性（Weak Consistency）：弱一致性和强一致性相反，读操作并不能保证可以取得最新一次写操作写入的数据，也就是说，客户端可能读到最新的数据，也可能读不到最新的数据。
最终一致性（Eventual Consistency）：最终一致性介于强一致性和弱一致性之间，写操作之后立即进行读操作，可能无法读到更新后的值，但是如果经过了一个指定的时间窗口，就能保证可以读到那个更新后的值。

互联网应用中最常见的几种架构技术，它们都是用以解决数据可用性的问题.

简单备份（Backup）指的就是定期或按需对存储系统中的数据全量或增量进行复制，并保存为副本，从而降低数据丢失风险的一种方式。

image.png

缺点:

Multi-Master 架构是指存在多个 Master（主）节点，各自都提供完整的读写服务，数据备份之间的互相拷贝为了不影响读写请求的性能，通常是异步进行的。

image.png

通常情况下节点之间的数据互拷贝是异步进行的，因此是最终一致性。需要说明的是，这个数据互拷贝理论上也是可以做到同步进行的，即将数据拷贝到所有其它的主节点以后再将响应返回给用户，而且那种情况下就可以做到强一致性，不过实际却很少有这样做的，这是为什么呢？

第一个原因，显而易见，同步的数据拷贝会导致整体请求响应的时延增加。
第二个，也是更重要的原因，如果有节点异常，这个拷贝操作就可能会超时或失败，这种情况下，你觉得存储系统应该怎样对待这个错误？显然，存储系统会陷入两难的境地。
如果系统容许错误发生，不返回错误给用户，那么强一致性就无法保证，既然无法保证，那么这个拷贝过程就完全可以设计成异步的，因为既然无论如何也无法保证强一致性，这个同步除了增加时延以外，并未带来任何明显的好处。
如果系统不容许错误发生，即返回错误给用户，一致性就被严格保证了，但是这样的话，整个存储系统就不再是高可用了，因为任何一个主节点的不可用，就会导致其它任意主节点向其拷贝数据的失败，进而导致整个系统都变得不可用。我们使用多个主节点的目的就是要提高可用性，而现在这样的设计和高可用性的目的就自相矛盾了。

缺点:

当我们要实现全局事务的时候，Multi-Master 往往不是一个好的选择。

Master-Slave 架构是指存在一个可读可写（或者只写）的 Master 节点，而存在多个只读的 Slave 节点，每当有通过 Master 的更新出现，数据会以异步的方式单向拷贝到所有的 Slave 节点上去。

image.png

这种方式比较适用互联网较常见的业务，即读远大于写的场景，而且读的可扩展性（Scalability）较强（即增加一个 Slave 节点的代价较小），而且不存在 Multi-Master 的事务冲突问题。

缺点:

还有其它更为复杂的方法，一种是 2PC 或 3PC，即两阶段提交或三阶段提交，甚至采用高容错的分布式的共识算法 Paxos。这些方法能够保证强一致性，但是在实现上都要复杂许多

image.png

简单说明一下，从上到下每行的含义依次为：一致性、事务支持、延迟、吞吐量、数据丢失和故障转移（指的是节点出现故障以后，其它节点可以自动顶替上来的能力）。

从中我们可以看到，没有一列能够做到全绿色，这正如我们所知道的那样，软件工程上的问题都“没有银弹”。特别是，Backups、M/S 和 MM 得益于异步的副本拷贝，能够做到低延迟，这就无法做到强一致性；而 2PC 和 Paxos 通过同步操作可以做到强一致性，却带来了高延迟。

公众号：码农架构