摘要：①定义：强一致性意味着在分布式系统中的每个读取操作，都能读取到最近写入的数据。也就是说，所有节点都始终保持相同的数据状态。

1、强一致性（Strong Consistency）

①定义：强一致性意味着在分布式系统中的每个读取操作，都能读取到最近写入的数据。也就是说，所有节点都始终保持相同的数据状态。

②特点：写操作对所有节点立即可见，所有的读取操作在任何节点上都能看到最新的写入。

③典型协议：如 Paxos、Raft 协议。

④优点：数据始终保持一致，不会出现数据冲突。

⑤缺点：性能开销较大，尤其是在跨区域的分布式系统中，延迟较高。

2、最终一致性（Eventual Consistency）

①定义：最终一致性意味着系统最终会达到一致的状态，但不保证任何时刻所有节点的数据一致。在某些时刻，不同节点的数据可能是不同的，但系统保证最终会同步并保持一致。

②特点：系统不保证即时一致性，但通过异步的方式在一段时间后使所有节点最终一致。

③典型协议：Amazon的Dynamo、Cassandra。

④优点：性能较高，延迟较低，适合高可用的应用场景。

⑤缺点：在某些情况下，可能会出现短期的不一致性，造成数据的冲突。

3、会话一致性（Session Consistency）

①定义：会话一致性是一种保证用户在单次会话期间读取到的数据一致性的模型。即使在分布式系统中有多个副本，在同一个会话中，用户的读取操作会返回一致的数据。

②特点：针对单个用户的操作，保证用户在会话中的一致性，但不同用户的会话可能会读取到不同版本的数据。

③适用场景：适用于用户体验要求较高的系统，比如一些在线购物网站，用户在会话内不会看到过期或不一致的购物车数据。

4、因果一致性（Causal Consistency）

①定义：因果一致性保证在分布式系统中，操作按照因果关系的顺序进行传播。如果操作A引起了操作B，那么所有读取操作将遵循这个因果顺序。

②特点：操作的顺序不强制，但如果存在因果关系，系统会确保这个关系得以遵循。

③优点：比强一致性具有更低的延迟，适用于一些需要保证因果顺序的应用（如社交网络中的帖子和评论）。

④缺点：比最终一致性略有开销，但性能要好于强一致性。

5、线性一致性（Linearizability）

①定义：线性一致性要求所有操作在系统中的执行顺序是一个全序，且系统中的每个操作必须遵循这个顺序。例如，读取操作必须看到最近的写操作，且所有的写操作都是全局可见的。

②特点：非常类似强一致性，但更为严格，保证了操作在时间上的顺序一致性。

③优点：保证了系统中操作的可预见性，用户读取的数据是最新的。

④缺点：较高的性能开销，可能会增加系统的延迟。

6、单调一致性（Monotonic Consistency）

①定义：单调一致性保证一个进程对数据的读取操作，永远不会读取到比之前更旧的数据版本。如果一个进程读取到了某个版本的数据，那么该进程随后的读取操作只能读取到更近的版本。

②特点：只保证读取到的数据不会“回滚”，即不能读取到较旧的版本。

③优点：相比强一致性，延迟较低，同时保证了操作的单调性。

④缺点：不能保证完全的一致性，可能会在某些场景中出现不一致。

在实际的分布式数据库实践中，常常根据应用需求选择适合的一致性模型。下面三种是最常用的几种一致性模式：

①最终一致性：对于需要高可用性和低延迟的应用，如社交媒体平台、推荐系统等，通常采用最终一致性模型。它的容错能力强，能保持系统的可用性，即使部分节点暂时不可用。

②强一致性或线性一致性：对于金融系统、银行、分布式事务等要求数据严格一致性的场景，通常采用强一致性模型或线性一致性模型。虽然这种一致性保证了数据的正确性，但它也带来了较高的延迟和性能开销。

③因果一致性：用于某些需要保持操作顺序的一致性而不强求即时一致性的场景，适用于社交网络、消息推送等。

在实际的分布式数据库中，像 Cassandra 或 Couchbase 这样的数据库通常选择最终一致性，因为它们需要在全球分布式环境中高效运作，而 Google Spanner 或 CockroachDB 则采用了强一致性或线性一致性来保证跨多个数据中心的数据一致性。

选择一致性模型的原因通常是基于以下几点：

①系统需求：如果业务要求数据的准确性和一致性（如金融交易），强一致性是必要的。如果更多关注的是高可用性和响应速度（如社交网络），最终一致性则更合适。

②延迟要求：强一致性模型通常会导致更高的延迟，影响系统的响应速度。根据实际场景选择合适的延迟和一致性平衡。

③故障容忍度：在高故障容忍要求的系统中，最终一致性模型通过牺牲一致性来提高可用性。

总之，不同的一致性模型在不同的业务场景下有不同的优势，实际选择时需要权衡一致性、可用性、分区容忍性等因素。

来源：灰灰龙猫