分布式理论--BASE

已于 2024-05-20 16:10:16 修改
阅读量406 收藏 4
点赞数 8
分类专栏： 分布式 架构设计 文章标签： 分布式 base 数据一致性 共识
于 2024-05-20 15:26:29 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37294163/article/details/139065714
版权

目录

是什么

在这里插入图片描述

  • BASE 理论是对 CAP 理论的进一步扩展
  • 主要强调在分布式系统中，为了获得更高的可用性和性能，可以放宽对一致性的要求，是对 CAP 中 AP 方案的一个补充。
  • BA（Basically Available）：基本可用，系统在面对分区故障时，允许牺牲部分可用性（比如响应时间延长点，系统的非核心功能暂不可用），并不是不可用。
  • S（Soft State）：软状态，允许系统中存在一种软状态（短时间内的数据不一致状态，如果是实时一致则为硬状态）
  • E（Eventual consistency）：最终一致性，虽然系统中存在数据不一致的状态，但是经过固定的时间间隔后，必须数据一致。也就是最终必须是一致的。

BASE 与 CAP，ACID 的区别

  • ACID 是事物的基本特性，属于单体系统的范畴，同时由于是本地事务，可以归属于强一致性模型
  • CAP 和 BASE 都是分布式系统的基本理论，BASE 又是 CAP 的进一步发展
  • CAP 中的一致性也可归属到强一致性模型，BASE 可以归属到弱一致性模型，BASE理论面向的是大型高可用、可扩展的分布式系统。

BASE 和 Paxos 类共识算法的区别

  • 一个是描述数据一致性的模型，一个是描述共识的模型
  • 数据一致性的目标是确保系统中的数据副本具有一致的状态，即任何时候任何节点的数据都是一致的。
    共识的目标是在面对部分节点故障或网络分区的情况下，使得系统能够就某个值或顺序达成一致，以保证系统的正确性和可用性。

相关问题

  • 数据一致性和共识的区别
  • 强一致性和弱一致性
  • 共识算法
追梦2222
关注
  • 8
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
大规模分布式存储系统
01-04
《大规模分布式存储系统：原理解析与架构实战》是分布式系统领域的经典著作，由阿里巴巴高级技术专家“阿里日照”（OceanBase核心开发人员）撰写，阳振坤、章文嵩、杨卫华、汪源、余锋（褚霸）、赖春波等来自阿里、新浪、网易和百度的资深技术专家联袂推荐。理论方面，不仅讲解了大规模分布式存储系统的核心技术和基本原理，而且对谷歌、亚马逊、微软和阿里巴巴等国际型大互联网公司的大规模分布式存储系统进行了分析；实战方面，首先通过对阿里巴巴的分布式数据库OceanBase的实现细节的深入剖析完整地展示了大规模分布式存储系统的架构与设计过程，然后讲解了大规模分布式存储技术在云计算和大数据领域的实践与应用。, 《大规模分布式存储系统：原理解析与架构实战》内容分为四个部分：基础篇——分布式存储系统的基础知识，包含单机存储系统的知识，如数据模型、事务与并发控制、故障恢复、存储引擎、压缩/解压缩等；分布式系统的数据分布、复制、一致性、容错、可扩展性等。范型篇——介绍谷歌、亚马逊、微软、阿里巴巴等著名互联网公司的大规模分布式存储系统架构，涉及分布式文件系统、分布式键值系统、分布式表格系统以及分布式数据库技术等。实践篇——以阿里巴巴的分布式数据库OceanBase为例，详细介绍分布式数据库内部实现，以及实践过程中的经验。专题篇——介绍分布式系统的主要应用：云存储和大数据，这些是近年来的热门领域，本书介绍了云存储平台、技术与安全，以及大数据的概念、流式计算、实时分析等。
springboot分布式集群.pdf
12-11
集群：分布式 1.集群：同一个业务，部署在多个服务器上(不同的服务器运行同样的 代码，干同一件事) 2.分布式：一个业务分拆多个子业务，部署在不同的服务器上(不同的 服务器，运行不同的代码，为了同一个目的) 3.当今是个分布式、集群、云计算等名词满天飞的时代。造成这种局 面的一个重要因素就是，单一机器的处理能力已经不能满足我们的需 求，不得不采用由多台机器组成的服务集群。服务集群对外提供服务 的过程中，可以分解处理压力，在一定程度上打破性能瓶颈，并提高 服务的可用性（不会因为一台机器宕机而造成服务不可用）。
分布式事物.txt
05-22
微服务分布式事物视频详解，TCC，BASE，MQ，2PC，最终一致
微服务--分布式事务的实现方法及替代方案
02-25
事务补偿机制:在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务.CAP理论:CAP(Consistency,Availability,PartitionTolerance),阐述了一个分布式系统的三个主要方面,只能同时择其二进行实现.常见的有CP系统,AP系统.幂等性:简单的说,业务操作支持重试,不会产生不利影响.常见的实现方式:为消息额外增加唯一ID.BASE(Basicallyavaliable,softstate,eventuallyconsistent):是分布式事务实现的一种理论标准.刚性事务是指严格遵循ACID原则的事务,例如单机环境下的数据库事务.柔性事
CAP理论+BASE理论
01-07
一. 简介 CAP理论：一个分布式系统不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition tolerance），最多只能同时满足两个（CA / CP / AP）。 一致性（Consistence）：在某个写操作完成后，任何读操作都能够获取到该写操作写入的最新值； 可用性（Availability）：非故障节点在合理的时间内能够做出合理的响应； 分区容错性（Partition tolerance）：分布式系统中的某个节点或者网络分区出现故障时，整个系统仍能提供满足一致性和可用性的服务。 BASE理论：系统放松对某一时刻数据强一致
分布式理论-BASE理论
wh柒八九的博客
04-30 537
BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。 文章目录CAP的3选2伪命题BASE理论简介 CAP的3选2伪命题 实际上，不是为了P（分区容错性），必须在C（一致性）和A（可用性）之间任选其一。分区的情况很少出现，CAP在大多时间能够同时满足C和A。 对于分区存在或者探知其影响的情况下.
分布式理论 - BASE
最新发布
激流丶的博客
06-06 915
BASE是分布式系统理论中的一个概念，它是对ACID（原子性、一致性、隔离性和持久性）的一种补充。BASE是基于CAP理论的，CAP理论指出，一个分布式系统无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个要求，只能同时满足其中的两个。
分布式系统-----BASE理论
weixin_40413961的博客
04-04 1179
分布式系统-----BASE理论 CAP理论是分布式系统的基石, 那么base理论就是分布式系统的台阶了，在基石上凿的台阶。 BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 BASE理论基本观点 1. 基本可用（Basically Available） 分布式系统，在出现故障的时候，允许损失部分
分布式--BASE理论
IT利刃出鞘的博客
02-14 321
本文介绍分布式中的BASE理论。
CAP理论与分布式数据库
02-27
根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。而传统数据库保证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大的NoSQL运动，就是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。但是，对于CAP理论也有一些不同的声音，数据库大师MichaelStonebraker就撰文《ErrorsinDatabaseSystems,EventualConsistency,andtheCAPTheorem》
关于分布式系统的思考
02-20
谈及一些分布式系统的理论和思想，包括CAP、BASE、NWR等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。在讨论常见架构前，先简单了解下CAP理论：CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指：一致性（Consistency）：每次读操作都能保证返回的是最新数据；可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果；分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。CAP理论指出：CAP三者只
分布式事务.png
06-14
分布式事务设计：分布式基础理论（TCC，BASE，2PS等），以及利用zookeeper作为控制中心设计分布式事物。
Taobao oceanbase代码
04-20
//供学习用，禁止用于商业用途。 2012.04.20 　　OceanBase解决什么问题 　　许多公司的核心资产是各种各样的商业数据，例如淘宝的商品、交易、订单、购物爱好等等，这些数据通常是结构化的，并且数据之间存在各种各样的关联，传统的关系数据库曾经是这些数据的最佳载体。然而，随着业务的快速发展，这些数据急剧膨胀，记录数从几千万条增加到数十亿条，数据量从百GB增加到数TB，未来还可能增加到数千亿条和数百TB，传统的关系型数据库已经无法承担如此海量的数据。OceanBase解决不断增加的结构化数据存储与查询的问题。 　　从Eric Brewer教授的CAP(一致性C: Consistency， 可用性A: Availability，分区容错性P: Tolerance of network Partition)理论角度分析，作为电子商务企业，淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性，数据特征是数据总量庞大且逐步增加，单位时间内的数据更新量并不大，但实时性要求很高。这就要求我们提供一套更加偏重于支持CA特性的系统，同时兼顾可分区性，并且在实时性、成本、性能等方面表现良好。 　　OceanBase的架构 　　OceanBase的逻辑架构简图　 　　▲ 　　OceanBase架构的一些基本概念 　　主键 　　row key，也称为primary key，类似于DBMS的主键，与DBMS不同的是，OceanBase的主键总是二进制字符串(binary string)，但可以有某种结构。OceanBase以主键为顺序存放表格数据 　　sstable 　　一种数据存储格式，OceanBase用来存储一个或几个表的一段按主键连续的数据 　　tablet 　　一个表按主键划分的一个(前开后闭的)范围，通常包含一个或几个sstable，一个tablet的数据量通常在256MB左右 　　基准数据和动态数据 　　OceanBase以增量方式记录一段时间内的表格数据的增删改，从而保持着表格主体数据在一段时间内相对稳定，其中增删改的数据称为动态数据(通常在内存，也称为内存表)，而一段时间内相对稳定的主体数据称为基准数据，基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储 　　ChunkServer 　　保存基准数据的服务器，通常是多台，为了避免软件硬件故障导致的服务中断，同一份基准数据通常保存了3份并存储在不同ChunkServer上 　　UpdateServer 　　保存动态数据的服务器，一般是单台服务器。为了避免软件硬件故障导致的服务中断，UpdateServer记录commit log并通常使用双机热备 　　MergeServer 　　进行静态动态数据合并的服务器，常常与ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据 　　RootServer 　　配置服务器，一般是单台服务器。为了避免软件硬件故障导致的服务中断，RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻，所以它常常与UpdateServer共用物理机器 　　冻结 　　指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后，OceanBase停止该块动态数据的修改，后续的更新写入新的动态数据块(即新的内存表)，旧的动态数据块不再修改，这个过程称为冻结 　　转储 　　出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘或磁盘上)的过程 　　数据合并(merge) 　　查询时，查询项的基准数据与其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外，把旧的基准数据与冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并 　　联表(join) 　　一张表与另一张或几张表基于主键的左连接关系，类似于DBMS的自然连接 　　COW 　　Copy on Write的缩写，在OceanBase中特指BTree在更新时复制数据备份写入，避免系统锁的技术手段 　　OceanBase的特点 　　OceanBase功能 　　OceanBase设计和实现的时候暂时摒弃了不紧急的DBMS的功能，例如临时表，视图(view)，研发团队把有限的资源集中到关键点上，当前OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入。 　　OceanBase数据访问特点 　　虽然数据总量比较大，但跟许多行业一样，淘宝业务一段时间(例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次)，根据这个特点，OceanBase把一段时间内的增删改等修改操作以增量形式记录下来(称之为动态数据，通常保存在内存中)，这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。 　　由于动态数据相对较小，通常情况下，OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。此外，假如每条修改平均消耗100 Bytes，那么10GB内存可以记录100M(即1亿)条修改，且扩充UpdateServer内存即增加了内存中容纳的修改量。不仅如此，由于冻结后的内存表不再修改，它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放，并仍然可以提供较高性能的读服务，这也缓解了极端情况下UpdateServer的内存需求。为了应对机器故障，动态数据服务器UpdateServer写commit log并采取双机(乃至多机)热备。由于UpdateServer的主备机是同步的，因此备机也可同时提供读服务。 　　因为基准数据相对稳定，OceanBase把它按照主键(primary key，也称为row key)分段(即tablet)后保存多个副本(一般是3个)到多台机器(ChunkServer)上，避免了单台机器故障导致的服务中断，多个副本也提升了系统服务能力。单个tablet的尺寸可以根据应用数据特点进行配置，相对配置过小的tablet会合并，过大的tablet则会分裂。 　　由于tablet按主键分块连续存放，因此OceanBase按主键的范围查询对应着连续的磁盘读，十分高效。 　　对于已经冻结/转储的动态数据，OceanBase的ChunkServer会在自己不是太繁忙的时候启动基准数据与冻结/转储内存表的合并，并生成新的基准数据。这种合并过程其实是一种范围查询，是一串连续的磁盘读和连续的磁盘写，也是很高效的。 　　传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间，但数据规模受到严重制约，缺乏扩展性;现代云计算提供了极大的数据规模、良好的扩展性，但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长，OceanBase的设计和实现融合了二者的优势： 　　-------------------------------------------------------------------------------- 　　UpdateServer：类似于DBMS中的DB角色，提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性。 　　ChunkServer：类似于云计算中的工作机(如GFS的chunk server)，具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点，系统容量及性能可随时扩展。 　　MergeServer：结合ChunkServer和UpdateServer，获得最新数据，实现数据一致性。 　　RootServer：类似于云计算中的主控机(如GFS master)，进行机器故障检测、负载平衡计算、负载迁移调度等。 　　-------------------------------------------------------------------------------- 　　上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间，还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。 　　OceanBase当前在淘宝的应用 　　OceanBase现在已经应用于淘宝收藏夹，用于存储淘宝用户收藏条目和具体的商品、店铺信息，每天支持4～5千万的更新操作。等待上线的应用还包括CTU、SNS等，每天更新超过20亿，更新数据量超过2.5TB，并会逐步在淘宝内部推广，也期待外部合作者。 　　主要的性能数据 　　测试软硬件环境 　　Red Hat Enterprise Linux Server release 5.4 (Tikanga) 　　gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) 　　Intel(R) Xeon(R) CPU E5520 @ 2.27GH 　　ChunkServer & MergeServer：Memory 16GB Disk 300GB SAS*10 NO Raid 　　UpdateServer & RootServer：Memory 48GB Disk 300GB SAS*6 Raid1 　　测试环境部署简图 　　▲ 　　测试数据规模 　　21亿条数据，基准数据3备份。 　　测试Schema 　　两张表，其中表1中有21列，表2中11列。 　　其中表1中的11列和表2中的11列存在join关系。 　　单条记录大小为500字节。 　　测试性能曲线图 　　Range数据查询 　　▲ 　　单条数据查询 　　▲ 　　当压力最大时，ChunkServer单台输出数据90MB/S，已经接近了千兆网卡的极限 　　更新数据 　　▲
分布式事务实践 解决数据一致性
11-23
第1章 课程介绍 介绍该课程的内容、学习成果、实例，还有学习所需的前提知识。 1-1 导学-分布式事务实践 第2章 事务原则与实现 介绍了事务的四大原则，并通过实例介绍数据库实现事务的方法，以及使用JDBC实现事务的方法。 2-1 事务原则与实现：事务 2-2 事务原则与实现：SQL事务 2-3 事务原则与实现：JDBC事务（上） 2-4 事务原则与实现：JDBC事务（下） 第3章 使用Docker搭建环境 介绍了Docker的使用，通过Docker将课程环境搭建起来，方便那些不了解这些技术的同学之后的学习。 3-1 docker简介与mysql安装-1 3-2 docker简介与mysql安装-2 3-3 SpringBoot基础 第4章 Spring事务机制 介绍了Spring的事务机制、事物抽象、内部事务和外部事物，以及常用的几种事务管理的实现，包括DataSource、JPA、JMS、JTA都通过实例进行说明。还有XA以及两阶段提交，并通过实例演示了使用JTA，通过两阶段提交，实现多数据源的事务实现。... 4-1 Spring事务机制_基本接口 4-2 Spring事务机制_实现 4-3 Jpa事务实例 4-4 Jms事务原理 4-5 Jms-session事务实例 4-6 Jms-spring事务实例 4-7 外部事务与JTA 4-8 JTA单数据源事务实例 4-9 JTA多数据源事务实例 第5章 分布式系统 介绍了分布式系统的定义、实现原则和几种形式，详细介绍了微服务架构的分布式系统，并使用Spring Cloud框架演示了一个完整的微服务系统的实现过程。 5-1 CAP原则和BASE理论简介 5-2 分布式系统综述 5-3 SpringCloud微服务架构 5-4 实现registry 5-5 实现proxy 5-6 user服务 5-7 order服务 5-8 添加hystrix 5-9 使用feign 5-10 优化服务间调用 第6章 分布式事务实现，模式和技术 介绍分布式事务的定义、原则和实现原则，介绍使用Spring框架实现分布式事务的几种方式，包括使用JTA、Spring事务同步、链式事务等，并通过实战介绍其实现。除此以外还介绍了一些分布式事务相关的技术，如幂等性、全局一致性ID、分布式对象等。... 6-1 分布式事务介绍 6-2 spring分布式事务实现_使用JTA 6-3 spring分布式事务实现_不使用JTA 6-4 实例1-DB-DB 6-5 实例1-DB-DB.链式事务管理器 6-6 实例2-JPA-DB.链式事务管理器 6-7 实例3-JMS-DB.最大努力一次提交 6-8 分布式事务实现模式与技术 6-9 全局一致性ID和分布式对象_ 第7章 分布式事务实现：消息驱动模式 详细介绍3种分布式事务实现的模式中的消息驱动模式并通过完整实例演示了消息驱动模式下，实现微服务系统的分布式事务的完整过程。 7-1 分布式事务实现：消息驱动模式 7-2 消息驱动模式实例：设计 7-3 消息驱动模式实例：创建ticket服务 7-4 消息驱动模式实例：实现基本ticket功能 7-5 消息驱动模式实例：锁票1 7-6 消息驱动模式实例：锁票2 7-7 按消息流程实现业务 7-8 支付过程 7-9 票转移 7-10 错误处理：锁票失败 7-11 错误处理：扣费失败 7-12 并发时的错误处理 第8章 分布式事务实现：Event Sourcing模式 详细介绍了分布式事务实现的模式中的Event Sourcing模式，并通过完整实例演示了Event Sourcing模式下，实现微服务系统的分布式事务的完整过程。 8-1 事件溯源模式介绍 8-2 事件溯源模式与Axon框架-1 8-3 事件溯源模式与Axon框架-2 8-4 使用Axon框架的设计过程介绍 8-5 Axon框架-实例（上） 8-6 Axon框架-实例（下） 8-7 Saga模式和Axon Saga 8-8 聚合命令事件（上） 8-9 聚合命令事件（下） 8-10 实现saga 8-11 实现query 8-12 处理超时 8-13 并发测试 8-14 cloud-axon实例：分布式处理介绍 8-15 事件设计 8-16 事件与队列设计 8-17 实现User服务 8-18 实现Ticket服务 8-19 实现Order服务 8-20 实现读写分离 8-21 测试与并发 8-22 事件溯源模式与Axon框架总结 第9章 TCC模式和微服务架构的设计模式 本章介绍TCC模式，也对微服务系统的几种设计模式，以及这些模式下分布式事务的实现模式进行了介绍。 9-1 TCC模式介绍 9-2 微服务架构的设计模式 第10章 课程总
分布式事务-BASE理论
lujiangui的专栏
10-04 307
由于CAP中一致性和可用性A无法兼得，EBay的架构师，提出来BASE理论，它是通过牺牲数据的强一致性，来获得可用性。它有以下3种特征： Basically Available（基本可用）：分布式系统在出现不可预知故障的时候，允许损失部分可用性，保证核心功能的可用。 Soft state（软状态） ： 软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 Eventually
分布式理论 - BASE理论学习
dream0130__的博客
07-27 140
前言 BASE理论是CAP理论中的AP的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。 BASE理论 BASE理论的核心是基本可用(Basically Available),软状态(Soft State)和最终一致性(Eventually Consistent)。软状态为不同节点之间，数据副本存在短暂的不一致性。 基本可用指的是当系统节点出现大规模故障的时候，通过牺牲部分功能的可用性，来保证系统的核心功能可用。 基本可用的本质是一种妥协，通过牺牲部分功能的可用性，来保证核心功能的稳定运行。
分布式理论-中间件
summer_fish的专栏
05-31 541
一、服务注册中心，是选择AP还是选择CP ？ 1、服务注册中心解决的问题 在讨论CAP之前先明确下服务注册中心主要是解决什么问题：一个是服务注册，一个是服务发现。 服务注册：实例将自身服务信息注册到注册中心，这部分信息包括服务的主机IP和服务的Port，以及暴露服务自身状态和访问协议信息等。 服务发现：实例请求注册中心所依赖的服务信息，服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。​​​​​​ 目前作为注册中心的一些组件大致有：D.
深入理解分布式技术 - BASE 理论
小工匠
01-03 9285
文章目录PreBase 理论概述 Pre 深入理解分布式技术 - 理论基石 CAP . CAP ，放弃强一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择。 在工程实践中，基于 CAP 定理逐步演化，提出了 Base 理论。 Base 理论概述 基本可用（Basically Available） 软状态（Soft State） 最终一致性（Eventually Consistent） Base 理论的核心思想是最终一致性，即使无法做到强一致性（Stron
分布式系统中base理论详解
04-23
分布式系统中的Base理论，是一个由Dynamo数据库团队提出来的理论，它是指： 基本可用（Basically Available）：系统能够在出现故障时继续运行，虽然可能只提供有限的功能。 软状态（Soft state）：指系统允许存在中间状态，而该状态不会引起系统级别的错误。 最终一致性（Eventual consistency）：指系统中的所有副本，在经过一段时间的同步后，最终会达到一致的状态。 Base理论着重强调了在分布式系统中，持续的可用性和性能远比绝对的一致性更加重要。它提出，当出现故障或不一致的情况时，系统应该尽快做出响应，然后再在后台进行数据同步和修复，以获得最终的一致性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值