分布式架构原理--CAP\Base理论及其应用

简介: 分布式架构原理专题: (演进过程及如何把应用从单机扩展的分布式;CDN加速静态文件访问;系统监控、容灾、存储动态扩容;架构设计及业务驱动分化;CAP\Base理论及其应用)

一、描述

CAP是分布式系统设计理论(C :Consistency一致性,A:Availability可用性,P:Partition Tolerance分区容错性),BASE是CAP理论中AP方案的延伸。

在分布式、微服务系统中,CAP定律三者无法同时兼顾,其中可以容忍网络之间出现的通讯故障,只能CP和AP二选一。
CP: 当网络出现故障之后,只能保证数据一致性,但是不能保证可用性(Zookeeper),意味着服务不能用;
AP: 当网络出现故障之后,不能保证数据一致性, 但是能保证可用性(比如Eureka),意味着可允许短暂的数据不一致性,但最终需达到一致,其他节点可正常提供服务;

image.png

一致性

指强一致性,在分布式系统中的同一数据有多个副本的情形下,对于数据的更新操作体现出的效果与只有单份数据是一样的。要求数据被一致地更新,所有数据变动都是同步的。
白话理解:
在设计设计或者部署一个分布式系统时,假设存在两个Redis库,分别是Redis主和Redis从库,用户在往数据库插入一笔记录 ,那么会在保存到数据库的同时也会实时的插入到Redis缓存中,并且主从库保持同步,如果这时候向数据库查询,在网络延迟的情况下,在同一时刻,Redis主和Redis从库查询到的数据应该是一致性的,每个节点的数据是相同的,不能允许有脏读。

可用性

客户端在任何时刻对大规模数据系统的读/写操作都应该保证在限定延时内完成。即系统在面对各种异常时,依然可以响应客户端的读/写请求并提供正常服务。
白话理解:
假设在分布式部署中,有以下集群部署节点,如果Tomcat1出现故障,Nginx会自动做故障转移,自动将请求转移到Tomcat2和Tomcat3,Nginx故障转移可帮助我们实现集群环境的可用性

分区容忍性

以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况(分布式系统一定会发生分区的情况的,因为存在网络中断、消息丢失等网络问题)。分区容忍性即指在网络中断、消息丢失的情况下,系统照样能够工作。
白话理解:
分区容错性是指系统能够容忍节点之间的网络通信的故障,假设我们有一台Tomcat服务器,部署在全国各地,像浙江节点、上海节点、武汉节点,但是可能出现其中某个节点由于网络故障不能使用,无法进行通讯;一般来说,现实中分区容错是无法避免的,因此可以认为 CAP的 P总是成立。CAP定理告诉我们,剩下的 C 和 A 无法同时做到。

BASE 理论

BASE 全称是 Basically Available(基本可用)、Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写,来自 ebay 的架构师提出。
image.png
1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性----注意,这绝不等价于系统不可用。比如:

(1)响应时间上的损失。正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障,查询结果的响应时间增加了1~2秒

(2)系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面

2、软状态
软状态指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性
最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

全文图片来源

目录
相关文章
|
8月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
11月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
230 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
10月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1398 3
|
8月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
8月前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
8月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
538 1
|
12月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
586 61
|
9月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
8月前
|
机器学习/深度学习 自然语言处理 监控
23_Transformer架构详解:从原理到PyTorch实现
Transformer架构自2017年Google发表的论文《Attention Is All You Need》中提出以来,彻底改变了深度学习特别是自然语言处理领域的格局。在短短几年内,Transformer已成为几乎所有现代大型语言模型(LLM)的基础架构,包括BERT、GPT系列、T5等革命性模型。与传统的RNN和LSTM相比,Transformer通过自注意力机制实现了并行化训练,极大提高了模型的训练效率和性能。
1765 0