顺序一致性到此为止，我们讨论了由领导者按照顺序处理读取的做法 。但是这种做法会产生一个瓶颈，从而限制系统的吞吐量 。最重要的是，领导者还需要联系大多数副本才能处理读取 。为了提高读取性能，我们应该允许副本处理请求 。
尽管副本会落后于领导者，但它接收到更新的顺序与领导者相同 。如果客户端A仅查询副本1，而客户端B仅查询副本2，则由于副本不完全同步，这两个客户端在不同时间点看到的状态也有所不同：
文章插图
在这个一致性模型中，对于所有观察者来说，操作发生的顺序相同，但操作的副作用何时会被观察者看到，该模型不能提供任何实时性的保证 。该模型称为顺序一致性 。顺序一致性与线性一致性之间的差异就在于前者缺乏实时性保证 。
这种模型的一个简单应用是与队列同步的生产者/消费者系统：生产者节点负责写入队列，而消费者则负责读取 。生产者和消费者看到队列各项的顺序相同，但消费者落后于生产者 。
最终一致性尽管我们设法提高了读取吞吐量，但我们不得不将客户端固定到某个副本上，此时如果副本出现故障该怎么办？为了提高存储的可用性，我们可以通过允许客户端查询任意副本 。但是，就一致性而言，这一步需要付出高昂的代价 。假设有两个副本1和2，其中副本2落后于副本1 。如果客户端在查询了副本2之后，紧接着又查询副本1，那么它将看到过去的状态，这可能会令人非常困惑 。客户端拥有的唯一保证是，如果系统的写入停止，则所有副本最终都将收敛到最终状态 。这种一致性模型称为最终一致性 。
在最终一致性的数据存储之上构建应用程序非常困难，因为其行为与你所习惯的编写单线程应用程序的行为不同 。任何一个细小的错误都可能逐步蔓延，而且很难调试和重现 。然而，并非所有应用程序都需要线性一致性，所以最终一致性也有一定的用武之地 。你需要做出明智的选择，仔细考虑你的数据存储提供的保证是否能够满足应用程序的需要 。如果你想记录网站的访问量，那么最终一致性将是你的首选，因为读取返回的数字是否有些过时并不重要 。但对于支付系统来说，强一致性绝对不可或缺 。
PACELC定理除了本文介绍的模型之外，还有很多有关一致性的模型 。但其背后的基本思想万变不离其宗：一致性保证越强，单个操作的等待时间就越长，而且发生故障时存储的可用性越低 。这种关系又称之为PACELC定理：在分布式计算机系统中进行网络分区（Partitioning，即P）的时候，我们必须在可用性（Availability，即A）和一致性（Consistency，即C）之间进行选择，否则（Else，即E）即便系统没有任何分区，我们也必须在延迟（Latency，即L）和一致性（Consistency，即C）之间进行选择 。
原文：https://robertovitillo.com/what-every-developer-should-know-about-database-consistency/
本文为 CSDN 翻译，转载请注明来源出处 。
【每位开发者都应了解的数据库一致性】
推荐阅读
- 软件|俄罗斯独立开发者太难了：软件能卖出去 收入转不到账上
- 如何加入华为鸿蒙？HarmonyOS的开发者环境下载与安装
- 开发者模式有什么用？
- 每个算法人员都应该知道的4个超参数调试方法
- Chrome开发者工具详解
- 16 个 PHP 开发者必知必会的魔术方法
- 微信推出开发者版：基于Android版v7.0.18
- 肾虚吃什么补 更年期肾虚推荐几款食疗
- 霍金|【每个职场人都应该明白的道理】眼里容不下沙子？你才是那颗沙子！！！
- 开发者手撸类谷歌搜索关键字智能匹配功能系统