前言

在分布式系统中，**一致性（Consistency）**始终是核心挑战之一。随着副本数量增多、跨机房部署的普及，我们必须权衡一致性、可用性和性能。在这种背景下，**Consistency Level（一致性级别）**概念被提出，让系统在不同业务场景下按需调整一致性强度，兼顾响应延迟与系统稳定性。

定义

wiki 定义如下：

Consistency level is a property of distributed systems that specifies how up-to-date and synchronized a replica of data must be before a read or write operation is considered successful.

一句话：一致性级别定义了客户端在读写操作中对数据一致性的要求。

工作原理

一句话：客户端通过指定一致性级别，控制读写操作需要多少副本响应，从而影响操作结果的一致性与延迟。

常见的读写过程如下：

  • 写：写请求发送到多个副本，只要满足设定的写一致性级别（如 2/3 副本写入成功）即可返回成功。
  • 读：从多个副本读取数据，读取数量取决于读一致性级别（如从 2 个副本读取，取最新值）。

通过协调读写的副本数量，可以实现不同程度的一致性、可用性和平衡性。

属性与指标

关注的一致性级别相关属性包括：

  1. 一致性强度（Consistency Strength） 强一致 → 最终一致，从高到低依次是：ALL > QUORUM > ONE > ANY > EVENTUAL。

  2. 可用性（Availability） 一致性越强，可用性越低，响应时间越长。

  3. 延迟（Latency） 低一致性设置（如 ONE）响应最快；ALL 延迟最高。

  4. 副本总数（Replication Factor, N） 影响可配置一致性级别的上限。

  5. 写/读一致性级别（Write/Read CL） 单独配置写和读的级别，搭配得当可实现强一致。

  6. W + R > N 公式 满足此条件时，可以保证强一致性。

类型

常见一致性级别（以 Cassandra 为例）

Level 描述 特性
ALL 所有副本必须响应 最强一致性，最低可用性
QUORUM 多数副本响应（如 N=3，需2个） 高一致性与可用性平衡
ONE 任意一个副本响应 延迟最低，但可能非最新数据
TWO/THREE 两个/三个副本响应 介于 ONE 和 QUORUM 之间
LOCAL_QUORUM 当前数据中心的多数副本响应 跨机房部署常用，减少延迟
EACH_QUORUM 每个数据中心的多数副本均需响应 跨机房强一致，代价最高
ANY 任意副本或 hinted handoff 成功即返回 写入最快但无法保证可读性

强 vs 最终一致性

一致性模型 特点 场景例子
强一致性 所有读写都反映最新状态 事务系统、金融系统
最终一致性 允许延迟，最终副本趋于一致 SNS、缓存系统、购物车等
可调一致性 可选具体级别（如 QUORUM） 大多数 NoSQL 数据库系统

应用场景示例

场景 推荐一致性级别
用户登录验证 QUORUM
活动页浏览统计 ONE 或 EVENTUAL
金融转账系统 ALL 或 QUORUM
电商下单 & 扣库存 LOCAL_QUORUM
多地协作办公文档 EACH_QUORUM

与程序的关系

  1. 业务驱动的一致性选择 不同业务需求容忍的数据一致性程度不同，开发者应灵活配置。

  2. 与可用性延迟的权衡 在系统压力或部分副本不可用时，较高一致性级别可能导致请求失败或变慢。

  3. 调优空间大 通过微调读写一致性级别、延迟容忍度、写入路径等，可以实现更稳健的系统行为。

  4. 可观测性支持 系统需提供一致性失败率、丢失写入、读非最新数据等指标用于监控。

常见支持一致性级别的系统

  1. Apache Cassandra（强支持）
  2. Amazon DynamoDB（支持 Strong 和 Eventual）
  3. ScyllaDB
  4. MongoDB（通过 ReadConcern、WriteConcern 实现）
  5. Couchbase
  6. FoundationDB
  7. Google Spanner（强一致全球分布）