一些分布式系统通过复制数据来提高系统的可爱型和容错性，并且将数据的不同副本存放在不同的机器上，由于维护数据副本的一致性代价很高，因此许多系统采用弱一致性来提高性能，一些不同的一致性模型也相继被提出，主要有以下几种：

  • 强一致性：无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。对于单副本数据来说，读写操作是在同一数据上执行的，容易保证强一致性，对多副本数据来说，则需要使用分布式事务协议（如两阶段提交或采用Paxos算法）
  • 弱一致性：如果能容忍后续部分访问不到最新的数据，则是弱一致性而不是全部访问不到。在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这一段时间称为“不一致窗口”。弱一致性有弱到什么程度的问题，因此根据弱的程度不同包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。
  • 最终一致性：是弱一致性的一种特例，在这种一致性下的系统保证用户最终能够取到某操作对系统特定数据的更新（读取操作之前没有该数据的其他更新操作）。此种情况下，如果没有发生失败，“不一致性窗口”的大小依赖于交互延迟、系统的负载及复制技术中副本的个数（这个可以理解为master/slave模式中，slave的个数）

最终一致性模型根据其提供的不同保证可以话费为更多的模型：

  • 因果一致性（Causal Consistency）：假如有相互独立的A、B和C三个进程对数据进行操作。进程A对某数据进行更新后并将该操作通知给B，那么B接下来的读操作能够读取到A更新的数据值。但是由于A没有将该操作通知给C，那么系统将不保证C一定能够读取到A更新的数据值。
  • 读自写一致性（Read Your Own Writes Consistency）：这个一致性是指用户更新某个数据后读取该数据时能够获取其更新后的值，而其他的用户读取该数据时则不能保证读取到最新值。
  • 会话一致性（Session Consistency）：是指读取自写更新一致性被限制在 一个会话的范围内，也就是说提交更新操作的用户在同一个会话里读取该数据时能够保证数据是最新的。
  • 单调一致性（Monotonic Read Consistency）：是指用户读取某个数据值，后续操作不会读取到该数据更早版本的值。
  • 时间轴一致性（Timeline Consistency）：要求数据的所有副本以相同的顺序执行所有的更新操作，另一种说法叫单调写一致性(Monotonie Wite Cnsiserey)。

    BASE（Basically Available, Soft-state, Eventual consistency）

    牺牲一致性，只是不再要求关系型数据库中的强一致性。从客户体验出发，最终一致性的关键是时间窗口，尽量达到“用户感知到的一致性”
  • 基本可用（Basically Available）：系统能够基本运行、一直提供服务
  • 软状态（Soft-state）：系统不要求一直保持强一致状态
  • 最终一致性（Eventual consistency）：系统需要在某一时刻后达到一致性要求

27CF9AC1D3E3815DE6B1F0773EDF06B4.jpg