分布式--BASE理论

IT利刃出鞘

已于 2025-08-23 17:32:29 修改

阅读量386

点赞数 20

CC 4.0 BY-SA版权

分类专栏：分布式文章标签：分布式

于 2022-02-14 00:05:49 首次发布

34 篇文章

订阅专栏

本文介绍了分布式系统中的BASE理论，即基本可用、软状态和最终一致性。在保证系统高可用性和分区容错性的前提下，牺牲强一致性，通过软状态和最终一致性达到数据的一致性。在实际应用中，根据业务场景选择ACID或BASE理论，以达到性能和一致性的平衡。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

简介

本文介绍分布式中的BASE理论。

对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。

Base理论：基本可用（Basically Available），软状态（Soft State），最终一致性（Eventually Consistent）

假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言有以下处损失：

响应时间上的损失：示例：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
功能上的损失：示例：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

硬状态：相对于原子性而言，要求多个节点的数据副本都是一致的。

软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

在实际工程实践中，最终一致性分为5种：

项	说明
因果一致性（Causal consistency）	如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。与此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
读己之所写（Read your writes）	节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
会话一致性（Session consistency）	会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读一致性（Monotonic read consistency）	如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
单调写一致性（Monotonic write consistency）	一个系统要能够保证来自同一个节点的写操作被顺序的执行。

在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

ACID能够保证事务的强一致性，即数据是实时一致的。这在本地事务中是没有问题的，在分布式事务中，强一致性会极大影响分布式系统的性能，因此分布式系统中遵循BASE理论即可。

分布式系统的不同业务场景对一致性的要求也不同。如交易场景下，就要求强一致性，此时就需要遵循ACID理论，而在注册成功后发送短信验证码等场景下，并不需要实时一致，因此遵循BASE理论即可。

要根据具体业务场景，在ACID和BASE之间寻求平衡。