CAP原理和BASE思想



分布式领域CAP理论,
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容忍性) 可靠性

定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区:
Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成。
Consistency一致性. 在事务开始或结束时,数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓。
Durability. 一旦事务完成,就不能返回。
跨数据库两段提交事务:2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,JavaEE中的JTA事务可以支持2PC。因为2PC是反模式,尽量不要使用2PC,使用BASE来回避。

BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性:
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步,异步。
Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时高一致。

BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片 

BASE思想主要强调基本的可用性,如果你需要High 可用性,也就是纯粹的高性能,那么就要以一致性或容忍性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。

现在NOSQL运动丰富了拓展了BASE思想,可按照具体情况定制特别方案,比如忽视一致性,获得高可用性等等,NOSQL应该有下面两个流派:
1. Key-Value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。

这两者共同点:都是关系数据库SQL以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度。

不同点:NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX,可以适合非Java如PHP RUBY等领域,是一种可以拿来就用的产品,而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的。

<think> 嗯,用户一口气提出了15个关于SpringCloud的深度问题,覆盖了微服务架构的核心知识点。从问题列表来看,用户应该是在准备面试或者系统学习微服务架构,需要全面且准确的技术解析。 用户引用的资料主要集中在Nacos的服务分级模型与Eureka的区别上,但实际需求远不止于此。特别注意到用户对分布式事务消息可靠性的关注,这两块是微服务中的难点。 先梳理问题框架: SpringCloud组件部分需要突出Netflix系Alibaba系组件的对应关系,比如EurekaNacos的并列关系。服务注册发现流程要强调健康检查机制这个核心。 关于Nacos分级存储模型,用户引用的[2][5]已经说得很清楚,三级结构(服务->集群->实例)是关键,需要补充集群配置的实操示例。 分布式事务部分,ATTCC的对比是重点。AT模式依赖全局锁解决脏写,而TCC需要业务改造但控制更细粒度。用户提到的脏读问题在AT模式下通过快照隔离解决。 RabbitMQ的消息可靠性需要分三个层面说:发送端确认、broker持久化、消费端手动确认。消息堆积的解决方案要区分临时处理架构优化。 限流算法部分,虽然用户没要求细节,但补充令牌桶漏桶的数学表达能提升专业性:设令牌生成速率$r$,桶容量$b$,则限流公式为$\min(r \times t + b, \text{请求量})$。 最后检查CAP理论的表述准确性:当网络分区(P)发生时,必须在一致性(C)可用性(A)间二选一,BASE思想强调基本可用最终一致。这些定义必须精确,避免误导用户。 </think>以下是针对微服务架构核心问题的系统解答,结合SpringCloud生态分布式系统原理: --- ### **一、SpringCloud常用组件及作用** 1. **Eureka/Nacos**:服务注册与发现中心 2. **Ribbon**:客户端负载均衡器 3. **OpenFeign**:声明式HTTP服务调用客户端 4. **Hystrix/Sentinel**:服务熔断与限流 5. **Gateway/Zuul**:API网关(路由、过滤) 6. **Config/Nacos Config**:分布式配置中心 7. **Sleuth/Zipkin**:分布式链路追踪 8. **Seata**:分布式事务解决方案 --- ### **二、服务注册发现基本流程** 1. **服务启动**:微服务向注册中心(如Nacos)发送注册请求,包含IP、端口、集群等信息[^3][^5] 2. **心跳维持**:临时实例定期发送心跳(如30秒),非永久实例需注册中心主动探测[^4] 3. **服务发现**:消费者从注册中心拉取服务列表并缓存 4. **服务调用**:消费者通过负载均衡策略选择实例发起调用 5. **状态更新**:注册中心推送变更通知,消费者更新本地缓存[^4] --- ### **三、Eureka vs Nacos区别** | **特性** | **Eureka** | **Nacos** | |------------------|------------------|----------------------------| | 一致性协议 | AP | AP/CP可切换[^4] | | 实例类型 | 仅临时实例 | 支持临时/永久实例[^4] | | 健康检查 | 客户端心跳 | 支持主动探测+心跳 | | 配置管理 | 不支持 | 原生集成 | | 雪崩保护 | 有 | 有 | | 权重/元数据 | 不支持 | 支持 | --- ### **四、Nacos分级存储模型** 采用**三级结构**: 1. **服务(Service)**:业务单元(如订单服务) 2. **集群(Cluster)**:逻辑分组(如北京集群、上海集群)[^5] 3. **实例(Instance)**:具体服务节点(IP:Port) **设计优势**: - 实现**同集群优先调用**,降低延迟[^2][^5] - 支持**跨集群容灾**(本地集群不可用时切换) - 通过权重配置实现灰度发布 --- ### **五、OpenFeign负载均衡实现** 1. **集成Ribbon**:自动将服务名解析为实例列表 2. **负载策略**: ```yaml # 配置集群优先规则 service-name: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule ``` 3. **调用过程**: `OpenFeign` → `Ribbon` → 根据策略(轮询/随机/权重)选择实例 → 发起HTTP请求 --- ### **六、服务雪崩与解决方案** **定义**:某个服务故障引发连锁反应,导致整个系统崩溃。 **解决方案**: 1. **熔断**:Hystrix/Sentinel监控失败率,触发熔断快速失败 2. **降级**:返回兜底数据(如默认值) 3. **限流**:控制并发调用量(见第八部分算法) 4. **异步通信**:MQ解耦服务调用 --- ### **七、Hystrix vs Sentinel** | **维度** | **Hystrix** | **Sentinel** | |----------------|--------------------------|----------------------------| | 熔断策略 | 基于错误率 | 支持QPS/错误率/响应时间 | | 规则配置 | 代码硬编码 | 控制台动态配置 | | 流量控制 | 简单计数器 | 滑动窗口/令牌桶 | | 系统自适应 | 不支持 | 支持系统负载保护 | | 生态整合 | Netflix体系 | 原生支持Spring Cloud Alibaba| --- ### **八、限流常见算法** 1. **计数器算法**:固定窗口计数,简单但临界突变 2. **滑动窗口**:细分时间窗口,精度更高 $$ \text{流量} = \sum_{i=1}^{n} \text{window}_i $$ 3. **漏桶算法**:恒定速率处理请求(FIFO队列) 4. **令牌桶算法**:以固定速率生成令牌,请求需获取令牌 $$ \text{可用令牌数} = \min(\text{桶容量}, \text{当前令牌} + r \cdot \Delta t) $$ --- ### **九、CAP理论与BASE思想** - **CAP**:分布式系统三要素 - **C**onsistency(一致性):所有节点数据相同 - **A**vailability(可用性):每次请求有响应 - **P**artition tolerance(分区容错性):网络分区时系统仍工作 > **定理**:网络分区下,C与A不可兼得[^4](如Nacos集群CP/AP切换) - **BASE思想**: - **B**asically **A**vailable(基本可用) - **S**oft state(软状态) - **E**ventual consistency(最终一致性) --- ### **十、分布式事务解决方案** | **方案** | **原理** | **适用场景** | |----------|------------------------------|-------------------| | **AT模式** | 自动补偿(回滚生成反向SQL) | 高并发简单事务 | | **TCC模式** | Try-Confirm-Cancel手动补偿 | 复杂业务逻辑 | | **Saga** | 长事务拆分+补偿事务 | 跨服务长流程 | | **MQ事务** | 消息表+最终一致性 | 异步解耦场景 | #### **AT模式解决脏读/脏写** - **脏写**:全局锁机制(事务1未提交时,事务2阻塞) - **脏读**:读取快照数据(Undo Log中的前镜像) #### **TCC vs AT 优缺点** | **模式** | **优点** | **缺点** | |----------|------------------------------|------------------------------| | **AT** | 无侵入、自动回滚 | 锁冲突高、不适用复杂业务 | | **TCC** | 高性能、细粒度控制 | 业务侵入性强、开发成本高 | --- ### **十一、RabbitMQ消息可靠性** 1. **生产者确认**: - `confirm模式`:消息到Exchange的确认 - `return模式`:消息无法路由到Queue的返回 2. **消息持久化**: ```java MessageProperties props = new MessageProperties(); props.setDeliveryMode(MessageDeliveryMode.PERSISTENT); // 持久化消息 ``` 3. **消费者确认**: - 手动ACK(消费成功后发送确认) ```yaml spring: rabbitmq: listener: simple: acknowledge-mode: manual # 手动ACK ``` --- ### **十二、RabbitMQ消息堆积处理** 1. **扩容消费者**:增加并发处理线程 ```yaml spring: rabbitmq: listener: simple: concurrency: 10 # 最小消费者数 max-concurrency: 50 # 最大消费者数 ``` 2. **批量消费**:一次处理多条消息 3. **队列拆分**:分多队列并行处理 4. **死信队列**:转移处理失败的消息 5. **限流保护**:防止消费者崩溃 ```yaml spring: rabbitmq: listener: simple: prefetch: 100 # 单次拉取消息数 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值