分布式系统架构常识:CAP理论。

简介: 什么是CAP理论?2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP,之后CAP理论正式成为分布式计算领域的公认定理。

什么是CAP理论?

2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP,之后CAP理论正式成为分布式计算领域的公认定理。

CAP理论是由下面三个概念组成的,且在分布式系统中三者不能兼得,只能同时满足两种条件。

一致性(C)

All nodes see the same data at the same time

所有数据库集群节点在同一时间点看到的数据完全一致,即所有节点能实时保持数据同步。

可用性(A)

Reads and writes always succeed

读写操作永远是成功的。即服务一直是可用的,即使集群一部分节点故障,集群整体还能正常响应客户端的读写请求。

分区容错性(P)

The system continues to operate despite arbitrary message loss or failure of part of the system

尽管系统中有任意的信息丢失或故障,系统仍在继续运行。以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

CAP权衡使用

1、保留CA,放弃P

如果想避免分区容错性问题的发生,一种做法是将所有的数据(与事务相关的)都放在一台机器上。虽然无法100%保证系统不会出错,但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。

作为一个分布式系统,放弃P,即相当于放弃了分布式,一旦并发性很高,单机服务根本不能承受压力。

像很多银行服务,确确实实就是舍弃了P,只用单台小型机+ORACLE保证服务可用性。

2、保留CP,放弃A

相对于放弃“分区容错性“来说,其反面就是放弃可用性。一旦遇到分区容错故障,那么受到影响的服务需要等待一定的时间,因此在等待期间系统无法对外提供服务。

作为分布式系统,有分区服务发生问题很有可能,如果因为某些服务不能用,导致整个服务都不能用,这个根本不是好的分布式系统。

3、保留AP,舍弃C

这里所说的放弃一致性,并不是完全放弃数据一致性,而是放弃数据的强一致性。即放弃了同一时刻的数据一致性,而保留数据的最终一致性。

以网络购物为例,对只剩下一件库存的商品,如果同时接受到了两份订单,那么较晚的订单将被告知商品告罄。

通常情况下,很多分布式服务系统都是采用该方案,保证可用性性,分布式服务,因为某些分区服务发生问题,先容忍,最终通过一些折中的方法达到最终数据一致性。

推荐阅读


去BAT面试完的Mysql面试题总结(55道,带完整答案)

阿里高级Java面试题(首发,70道,带详细答案)

2017派卧底去阿里、京东、美团、滴滴带回来的面试题及答案

Spring面试题(70道,史上最全)

通往大神之路,百度Java面试题前200页。

分享Java干货,高并发编程,热门技术教程,微服务及分布式技术,架构设计,区块链技术,人工智能,大数据,Java面试题,以及前沿热门资讯等。


相关文章
|
3月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
6月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
115 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
3月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
3月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
370 1
|
4月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
7月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
426 61
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
806 8
|
8月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2952 57
|
8月前
|
NoSQL 关系型数据库 MySQL
分布式系统,从CAP定理说起
本文作者笠泱分享了对分布式系统及其核心理论的理解,包括分布式系统的概念、单体架构的局限性以及网络运算常见误区。重点解析了CAP定理(一致性、可用性、分区容错性三者不可兼得)和BASE理论(基本可用、软状态、最终一致性)。同时探讨了如何判定CP与AP系统,并结合Nacos、MySQL、Redis等实例分析其特性。最后总结分布式架构设计需关注高可用、高性能等六大指标,强调微服务与分布式解决方案的重要性。
656 14
|
8月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
554 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡