《NoSQL权威指南》——1.7 服务器端一致性

1.7 服务器端一致性

在服务器端，我们可能在几个节点，但不一定是所有的节点，拥有相同的数据。如果所有n个节点都在一个数据值上达成一致，那么我们确定这个数据就是对的。生活是美好的。

但是，在针对“更新”建立共识的过程中，我们需要知道到目前为止邮件列表外有多少节点确认收到更新。我们正在寻找一个仲裁规则来审计节点故障和不完整复制。这些规则与应用程序不同。大型银行转账可能想要在所有节点上完全一致。一个网站购物车应用程序只要满足下面的条件就是令人满意的：客户返回给任何服务节点购物车的某个版本，用户就可以继续购物，即使有一些丢失的物品也没关系。只要确保当用户点击“结账”按钮时其他节点知道要删除其购物车的本地副本就可以。

我们不希望将节点的突发紧急重新启动作为默认动作。早期的文件系统是就是以这种方式工作的。几十年前，我的妻子为处理社会保障数据的保险公司工作，一个打卡故障会中止整批处理，并发出无用的错误消息。

我们希望系统会设计有优雅的降级机制。Sabre的航空订票系统会排出少量的重复订票。如果某个人有两次冲突的或冗余的订票，不会有什么问题，因为一名乘客无法同时做两个座位，在同一个座位也无法乘坐两次，问题会通过人为方式或者问题本身的逻辑来解决。

当某一个节点过载时，你可能会容忍降低性能并将部分负载迁移到其他节点，直到第一个系统得以修复。最好的例子是独立磁盘冗余阵列（redundant array of independent disks，RAID）系统。当一个磁盘发生故障时，它在物理上从阵列中删除并插入一个新的单元来取代它。在故障磁盘重建的过程中，访问的性能将会有一点点下降。在系统继续运行其日常任务时，数据必须从被替换阵列磁盘中复制到新磁盘。