当前位置: 首页 > news >正文

分布式架构:解读不同数据一致性模型

文章目录

  • Pre
  • 引言
  • BASE 理论概述
  • BASE 三要素详解
    • 1. 基本可用(Basically Available)
    • 2. 软状态(Soft State)
    • 3. 最终一致性(Eventually Consistent)
  • 全局时钟 vs 逻辑时钟
  • 不同数据一致性模型及其应用
    • 强一致性(Linearizability)
    • 弱一致性(Weak Consistency)
    • 最终一致性(Eventual Consistency)
    • 因果一致性(Causal Consistency)
    • 会话一致性(Session Consistency)
  • CAP 与 BASE 的关系

在这里插入图片描述


Pre

分布式缓存:CAP 理论在实践中的误区与思考

分布式缓存:BASE理论实践指南

分布式 - 从CAP到PACELC_分布式系统的一致性与可用性权衡

架构思维:从CAP到PACELC到BASE

分布式架构:证明分布式系统的 CAP 理论


引言

在分布式系统中,数据一致性是设计和实现的核心挑战之一。为了提高系统的可用性和分区容错能力,我们往往不得不在一致性上做出一定的让步。分布式架构:证明分布式系统的 CAP 理论中我们基于 CAP 定理,讨论了牺牲强一致性以换取可用性和分区容忍性的设计选择。接下来将继续深入,基于 CAP 演化出的 BASE 理论——以及其衍生的各种一致性模型——来分析它们在不同场景下的应用。


BASE 理论概述

BASE 是 “Basically Available(基本可用)”、“Soft State(软状态)” 和 “Eventually Consistent(最终一致性)” 三个短语的首字母缩写。

在这里插入图片描述

  • 核心思想:在无法实现强一致性的前提下,通过设计让系统在故障和网络分区时依然可用,并最终达到一致状态。
  • 适用范围:典型的 NoSQL 存储、微服务架构及需要高可扩展性的分布式系统。

BASE 三要素详解

1. 基本可用(Basically Available)

  • 定义:系统不追求“任何时候读写必定成功”,而是即使部分节点故障或网络异常,也能保证主要服务持续可用。
  • 表现形式:可能出现请求排队、限流或降级服务,但最终不会全面宕机。
  • 示例: 当 QPS 峰值超载时,使用排队或限流策略保护系统,确保核心功能(如下单入口)可用。

在这里插入图片描述


2. 软状态(Soft State)

  • 定义:允许数据在各节点间存在中间不一致状态(“软”),不强制立即同步。
  • 对比 ACID 原子性:ACID 中的“原子性”要求多个副本同时更新成功或同时失败(硬状态);软状态则容忍短暂差异。
  • 实例:在支付场景中,订单系统将状态标记为“支付中”后,可能暂未同步到所有节点,此时任一节点读取到的状态可能不同。

3. 最终一致性(Eventually Consistent)

  • 定义:系统保证在某个时间窗口后,所有副本会同步到相同状态。
  • 影响因素:网络延迟、系统负载、复制方案等都会影响不一致窗口的时长。
  • 实现方式:异步复制、定时补偿、重试机制、消息队列等手段。

全局时钟 vs 逻辑时钟

分布式系统解决了传统单体架构的单点问题和性能容量问题,另一方面也带来了很多新的问题,其中一个问题就是多节点的时间同步问题:不同机器上的物理时钟难以同步,导致无法区分在分布式系统中多个节点的事件时序。

没有全局时钟,绝对的内部一致性是没有意义的,一般来说,我们讨论的一致性都是外部一致性,而外部一致性主要指的是多并发访问时更新过的数据如何获取的问题。

  • 全局时钟问题:不同机器的物理时钟无法精确同步,导致分布式事件顺序难以判断。
  • 逻辑时钟:基于事件顺序(如 Lamport 时钟、向量时钟)来记录因果关系,而非依赖物理时间。
  • 应用场景:逻辑时钟用于实现因果一致性,确保有因果关系的操作按照正确顺序生效。

不同数据一致性模型及其应用

在这里插入图片描述

强一致性(Linearizability)

  • 定义:写操作完成后,任何后续读都可以读取到最新的值。
  • 优势:最符合用户直觉,保证“读己所写”。
  • 代价:需要同步多副本的确认,牺牲可用性或性能。
  • 典型应用:分布式事务管理、金融核心系统、库存扣减场景。

弱一致性(Weak Consistency)

  • 定义:系统在写入成功后,不保证立即可读最新值,也不保证具体时间。存在“不一致性窗口”。
  • 适用:对实时性要求不高,但对可用性要求极高的业务。

最终一致性(Eventual Consistency)

  • 特例:弱一致性的一种,强调“保证最终一致”。
  • 应用场景:社交媒体动态分发、商品访问信息统计、大规模日志处理。

因果一致性(Causal Consistency)

  • 定义:保证有因果关系的操作顺序,非因果操作可并行。
  • 示例:在微博评论场景中,“评论→回复”必须有序,其他无关评论可不同步。

会话一致性(Session Consistency)

  • 定义:在同一客户端会话内,保证“读己所写”。
  • 应用:用户会话场景,如分布式 Session 存储、个性化设置更新。

CAP 与 BASE 的关系

  • CAP 理论:在网络分区时,必须在一致性 © 与可用性 (A) 之间做权衡。
  • BASE 理论:将 CAP 的折中落地——放弃强一致性(C),追求基本可用(A)和分区容错 §。
  • 实践启示:大多数分布式系统(如 NoSQL 数据库、微服务)选择 BASE 模式,通过限流、降级、最终一致性等手段保证可用。

在这里插入图片描述

相关文章:

  • stm32f系列工程切换到H系列
  • Qwen3内置提示词模板解读
  • 企业微信内部网页开发流程笔记
  • 嵌入式学习--江协stm32day3
  • JavaScript- 3.2 JavaScript实现不同显示器尺寸的响应式主题和页面
  • Java spingboot项目 在docker运行,需要含GDAL的JDK
  • 用C#最小二乘法拟合圆形,计算圆心和半径
  • LabVIEW教学用开发平台
  • 深入理解设计模式之命令模式
  • 【Web应用】基础篇04-功能详解-权限控制(创建菜单--分配角色--创建用户)
  • maven 最短路径依赖优先
  • c#基础08(数组)
  • 第十章:构建之巅 · 打包与部署的终极试炼
  • 实验设计与分析(第6版,Montgomery)第3章单因子实验:方差分析3.11思考题3.1 R语言解题
  • Docker常用操作
  • 下一代 SaaS 平台的 AI 架构重构路径——多租户 AI 服务调度 · 多角色智能辅助 · 嵌入式 AIGC 能力的融合设计
  • 欧几里得 ---> 裴蜀定理 ---> 拓展欧几里得
  • OpenCV CUDA模块图像处理------颜色空间处理之拜耳模式去马赛克函数demosaicing()
  • HarmonyOS NEXT~鸿蒙系统运维:全面解析与最佳实践
  • el-tree拖拽事件,限制同级拖拽,获取拖拽后节点的前后节点,同级拖拽合并父节点name且子节点加入目标节点里
  • 个人博客网站备案吗/营销方式和手段
  • 做网站怎样找/手机如何制作一个网页链接
  • 找个做网站的/推广网站都有哪些
  • wordpress云盘视频播放/整站seo优化公司
  • 淘宝下载安装/贵州萝岗seo整站优化
  • python做网站难么/91手机用哪个浏览器