实现线性一致性（线性化）
线性一致性就是像“只有一个数据库节点”。使用单一节点是一个方法，但是单一节点的方案不能容错。为了容错，需要使用备份。之前讨论过几种备份方案，看看它们是否能线性化。
1、单主节点备份（潜在线性化）
使用单主节点备份的系统，所有的写入首先会发送至主节点，然后会备份至从节点。如果从主节点读取或者是同步更新的节点读取，那么天然就是线性的。但是如果主节点出现故障，进行故障转移，那么新的主节点可能丢失最近的写入，这违背了持久化和线性化。
2、共识算法（线性化）
共识算法类似单主节点备份，可以实现线性化存储。
3、多主节点备份（非线性）
多主节点备份系统一般不是线性的，它们会在多个节点上处理写入，然后异步分布到其他节点。
4、无主节点备份（可能非线性）
线性一致和阈值
凭直觉， Dynamo类型的模型中严格使用阈值协议的读取和写入应该是线性的。但是因为网络延迟，它可能会产生竞态条件。如图9-6.
线性一致的代价
之前讨论过，一些备份方法可以提供线性一致性，但是另一些不可以。需要讨论它们的优劣。
对于多个数据中心来说，使用多主节点备份是个好的选择，但是如果发生了网络故障，那么需要在线性化和可用性之间做出选择，如图9-7
如上图所示，如果两个数据中心之间发生网络故障，客户端可以连接数据库，但是数据库节点之间无法互联。这时，数据库仍然可以工作，只是需要备份的写入堆积了。
另一方面，如果使用单主节点备份方式，两个数据中心之间发生了网络故障时，那么连接从节点的客户端无法写入，也无法读取到最新的数据。
CAP理论
上述问题，不仅发生在多主节点备份和单主节点备份之间，任何线性化的数据库都可能发生这类问题。也不仅局限于多个数据中心。任何网络不可靠的场景都可能发生，甚至是同一个数据中心里。
1、如果应用需要线性一致，那么一些备份因为网络问题而失去连接时，那部分备份因为失联而无法处理请求，需要等到网络问题修复后；也就是它们不可用。
2、如果应用不需要线性一致，那么每个备份都可以处理请求，即便是与其他备份失去了联系；这种情况下，失联的备份依然是可用的，但是行为并不是线性一致的。
不需要线性一致的系统更能容忍网络错误。这个就是CAP定理。CAP一般描述为：一致性，可用，容忍分区这三个特性中，只能满足两个。但是这种表述具有误导，因为网络错误无法避免，人并不能主观选取。所以一个更好的表述就是，一致性或者是分区时可用。另外CAP考虑的范围很窄，只考虑了一致性和一种错误（网络错误）。没有考虑其他的网络延迟，节点故障，故障转移等问题。所以CAP只有历史意义，无法作为现在的设计指导思想。
线性一致和网络延迟
线性一致是个很有用的特性，但是很少有系统使用它。比如多核CPU就不是线性的：如果一个线程往内存中写入了一个值，运行在另一个核上的线程很快的在相同地址读取，那么并不保证读取到刚才写入的值（除非使用内存屏障）。原因是每个CPU的核都有自己的缓存，内存首先接触到的是CPU的缓存，任何写入会异步写入值主内存，这种设计有利于提高CPU的性能；但是因为一个数据在多个地方有备份，并且这些备份并不是同时更新的，所以损失了线性一致性。为什么作出这种取舍？我们并不期望CPU在与电脑其他部分失去仍然能正常工作，我们是为了性能而放弃线性一致性，而不是为了容忍故障。很多系统也是因为同样的原因放弃了线性一致：为了性能。线性一致性比较慢，不管有没有网络故障。
扫一扫
1607
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
