在上一篇文章里忽略了一点。
CAP 定理有一个缺陷,这个缺陷可以帮助我们“部分”摆脱 分布式困境。
总的来说,CAP 定理本身是完备的,但它并没有描述一个分布式系统何时产生分区,以及分区会持续多长时间。理论其实只限制:在分区发生的 时间内,系统只能在一致性(C)和可用性(A)之间二选一。
因此,分布式系统完全可以在没有出现分区时保证 C 和 A,而在出现分区后,放弃一些 A 或者 C 然后通过人工操作消除分区,让系统恢复到分区前的状况。
这样说太复杂了。用 说人话 的方式就是:
※ 当没有故障时,系统正常处理请求并且返回一致的结果。
※ 出现故障后,首先把所有请求切换到正常机器,故障机器下线。
※ 接着人工恢复故障机器上的数据,保证数据一致性。
※ 最后让机器重新上线,恢复系统正常容量。
基本上(请忽略一些细节),这就是主备同步的数据库集群在故障恢复时的做法。
这里的思路是,既然 CAP 特性在一个时间点不可能同时满足,那我们可以在这个时间点暂时放弃 A 或者 C,然后在另一个时间点再设法恢复。只要恢复的速度足够快,用户就能够忍受暂时的不一致或者不可用。
“Twitter 只是暂时不可用,最终会恢复可用。”
沿着这个思路,业界产生了一些理论,其中最著名的是 BASE。
BASE, 最终一致性
这个理论由 Basically Available, Soft state, Eventual consistency 组成。核心的概念是 Eventual consistency ——最终一致性。它局部的放弃了 CAP 理论中的“完全”一致性,提供了更好的可用性和分区容忍度。
Basically Available
基本可用, 或者说部分可用。由于分布式系统的节点故障是常见的,业务必须接受这种不可用,并且做出选择:是访问另一个节点忍受数据的临时不一致,还是等待节点恢复并忍受业务上的部分不可用。
Soft state
把所有节点的数据 (数据 = 状态) 都看作是缓存(Cache)。适当的调整业务,使业务可以忍受数据的临时不一致,并保证这种不一致是无害的,可以被最终用户理解。
Eventual consistency
放弃在任何时刻、从任何节点都能读到完全一致的数据。允许数据的临时不一致,并通过异步复制、重试和合并消除数据的临时不一致。
注意 在分布式系统中,写入和读取可能发生在不同的节点上。最终一致带来的问题是,业务在写入后立即读取,很可能读不到刚刚写入的数据。因此需要一个附加约束:
RYW (Read-Your-Writes) consistency
RYW consistency 是弱化的因果一致性(Causal consistency),它保证业务在会话中一定能读到上一次写入的数据。会话可以看作是同一个连接,或者是同一个 HTTP Session。例如:用户刚刚创建了一个订单,在提交后他可以立刻查看这个订单,这就是 RYW 一致性。
ACID 与 BASE
BASE 这个缩写有些拼凑的痕迹。那是因为作者认为它的含义与 ACID 恰好相反。
在英文词典里,ACID 代表 酸(Acid),而 BASE 代表 碱(Base)。就像这两个单词在化学中的含义一样 —— ACID 与 BASE 位于 CAP 理论的两端,代表了分布式系统的两种选择。
传统数据库用 ACID 保护业务数据的一致性。它明确的要求:事务必须保证数据从上一个一致性状态进入下一个一致性状态,事务的结束和数据的一致性之间没有时差。
从 CAP 定理我们可以知道:正是 ACID 要求的这种“强”一致性,使得事务系统只能选择 C-A 或者 C-P。第一个选择实际上是单机的传统数据库,第二个选择是后面将要介绍的强一致性的数据复制集群。
而 BASE 代表了另一种选择:放弃一致性 来保证分布式系统的高可用。与 ACID 的做法相反:业务需要接受和处理数据的不一致,并且保证这些不一致不会破坏业务约束 —— 这需要设计者对可能产生的数据不一致和业务约束非常了解,并且带来了更高的复杂度。
选择 高可用 的价值在于:很多场景下系统不可用就意味着对外停止服务,对用户的影响和商业风险远远比“系统仍然可用但是要过一会才能看到数据”来得严重。在一些场景下,用户或许根本不在乎过一会才能看到数据,例如 银行跨行转账。但是,如果银行告诉用户无法进行跨行转账,那么就会有很多用户质疑或投诉银行的服务了。
上面的 CAP 拼图里还剩下一个区域。前面讨论过的 ACID 理论占据了 C-A 区域,代表根本无法容忍分区的传统单机数据库。本文介绍的 BASE 理论位于 A-P 区域,代表部分放弃一致性、追求高可用的现代业务系统。
因此在这幅拼图里还剩下 C-P:能够在分布式环境下 保证数据一致性 的理论。
下一篇准备介绍这一部分理论。敬请期待。
相关推荐
漫谈兼容内核之一:ReactOS怎样实现系统调用 漫谈兼容内核之二:关于kernel-win32的对象管理 漫谈兼容内核之三:Kernel-win32的文件操作 漫谈兼容内核之四:Kernel-win32的进程管理 漫谈兼容内核之五:Kernel-win32...
在.NET 4.0面向对象编程漫谈基础篇中,金旭亮详细介绍了.NET框架下的面向对象编程的基础知识和技巧。面向对象编程(Object-Oriented Programming,OOP)是一种编程范式,它使用“对象”来设计软件。对象可以包含数据...
.NET 4.0面向对象编程漫谈应用篇是一本专注于.NET 4.0框架下进行面向对象编程技术的电子书籍。作者金旭亮将其专业见解和实践经验融入到这本书中,让读者在应用层面上深入理解面向对象编程(Object-Oriented ...
「端点安全」跨越攻防的壁垒_漫谈企业内部安全蓝军建设实践 - 安全方案 企业安全 企业安全 NGFW 安全对抗 端点安全
此外,消费者的娱乐、教育甚至与政府事务的处理方式也因电子商务而发生改变,支付方式的电子化也使得消费过程更加便捷。 对市场的影响主要体现在市场的细分、虚拟化、多样化、个性化和全球化上。电子商务推动了市场...
综上所述,《星际旅行漫谈》通过对光速旅行、时间机器和虫洞等概念的深入探讨,不仅呈现了人类探索宇宙的梦想与追求,也为读者展现了科学技术进步所带来的无限可能。尽管目前这些概念大多停留在理论阶段,但随着科学...
本文件提供信息安全基本知识,面向普通人群尤其是IT技术人员,通过案例和深入浅出的讲解,让听者掌握基本的信息安全知识、理念、理论和技能。适合于各类科技公司、院校和研究院所。
漫谈WebLogic-CVE-2020-25511
分布式Key Value Store漫谈
- **AS/400e 商用服务器**:AS/400e以其集成性、开放性、可移植性、兼容性、可连接性和可扩充性,成为中小型企业的理想选择。 - **Netfinity 服务器**:基于Intel芯片的企业级服务器,通过集群技术,实现了高可用...
同时,电子商务还能提高企业的亲和力,如消费者可以直接与企业高层交流,增强了消费者的信任感。 其次,电子商务能显著降低成本,增强企业的竞争优势。在采购环节,通过信息化和自动化,企业可以降低信息处理和人员...
合约的交易单位为20吨/手,最低交易保证金为5%,价格波动幅度限制在上一交易日结算价的±4%。 【宏观概况】尿素市场受多种因素影响,包括环保政策的严格、农业化肥需求的下降以及全球产能的持续增长。中国的尿素...
这个过程确保了分布式事务的原子性和一致性。 【事务处理的四种方式】 1. SQL 事务: 直接在SQL Server存储过程中使用BEGIN TRAN、COMMIT TRAN和ROLLBACK TRAN语句来管理事务。这种方式效率高,但局限于数据库内部...
根据 Infonetics 研究报告指出,托管式 IPPBX 和融合通信市场将以每年至少 20%的增长。 由此不难看出,2016 年 SBC 市场将以大幅度增长。统计数据表明用户需求数量的增加必然 带动厂家设备的销售额。...
#资源达人分享计划#
漫谈兼容内核之一:ReactOS怎样实现系统调用 漫谈兼容内核之二:关于kernel-win32的对象管理 漫谈兼容内核之三:Kernel-win32的文件操作 漫谈兼容内核之四:Kernel-win32的进程管理 漫谈兼容内核之五:Kernel-win32...
华为防火墙技术漫谈,理论篇共包含十章,涵盖了会话与状态检测、安全策略、攻击防范、NAT、GRE 、L2TP 、IPSec 、SSL、双机热备、出口选路的原理、应用场景及配置方法
谈兼容内核之一:ReactOS怎样实现系统调用.pdf 漫谈兼容内核之二:关于kernel -win32的对象管理.pdf 漫谈兼容内核之三:关于kernel-win32的文件操作.pdf 漫谈兼容内核之四:Kernel-win32的进程管理.pdf 漫谈兼容内核...
Dubbo分布式服务架构,对于研究大型Web服务器的并发技术的同学们有帮助。