分布式架构原理--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、最终一致性
最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

全文图片来源

目录
相关文章
|
10月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
10月前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
10月前
|
机器学习/深度学习 自然语言处理 监控
23_Transformer架构详解:从原理到PyTorch实现
Transformer架构自2017年Google发表的论文《Attention Is All You Need》中提出以来,彻底改变了深度学习特别是自然语言处理领域的格局。在短短几年内,Transformer已成为几乎所有现代大型语言模型(LLM)的基础架构,包括BERT、GPT系列、T5等革命性模型。与传统的RNN和LSTM相比,Transformer通过自注意力机制实现了并行化训练,极大提高了模型的训练效率和性能。
2343 0
|
安全 JavaScript 前端开发
HarmonyOS NEXT~HarmonyOS 语言仓颉:下一代分布式开发语言的技术解析与应用实践
HarmonyOS语言仓颉是华为专为HarmonyOS生态系统设计的新型编程语言,旨在解决分布式环境下的开发挑战。它以“编码创造”为理念,具备分布式原生、高性能与高效率、安全可靠三大核心特性。仓颉语言通过内置分布式能力简化跨设备开发,提供统一的编程模型和开发体验。文章从语言基础、关键特性、开发实践及未来展望四个方面剖析其技术优势,助力开发者掌握这一新兴工具,构建全场景分布式应用。
1231 35
|
存储 监控 算法
园区导航系统技术架构实现与原理解构
本文聚焦园区导航场景中室内外定位精度不足、车辆调度路径规划低效、数据孤岛难以支撑决策等技术痛点,从架构设计到技术原理,对该系统从定位到数据中台进行技术拆解。
694 0
园区导航系统技术架构实现与原理解构
|
存储 消息中间件 canal
zk基础—2.架构原理和使用场景
ZooKeeper(ZK)是一个分布式协调服务,广泛应用于分布式系统中。它提供了分布式锁、元数据管理、Master选举及分布式协调等功能,适用于如Kafka、HDFS、Canal等开源分布式系统。ZK集群采用主从架构,具有顺序一致性、高性能、高可用和高并发等特点。其核心机制包括ZAB协议(保证数据一致性)、Watcher监听回调机制(实现通知功能)、以及基于临时顺序节点的分布式锁实现。ZK适合小规模集群部署,主要用于读多写少的场景。
|
机器学习/深度学习 算法 测试技术
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析
本文探讨了基于图的重排序方法在信息检索领域的应用与前景。传统两阶段检索架构中,初始检索速度快但结果可能含噪声,重排序阶段通过强大语言模型提升精度,但仍面临复杂需求挑战
548 0
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析

热门文章

最新文章