CAP原理+BASE

CAP

C:Consistency(强一致性)
A:Availability(可用性)
P:Partition tolerance(分区容错型)

关系型数据库可以满足传统的关系ACID
非关系型数据库只可以满足两种特性

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以
分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡,
没有NoSQL系统能同时保证这三点。

怎样选择?

CA 传统Oracle数据库
AP 大多数网站架构的选择
CP Redis、Mongodb

注意:分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。
因此牺牲C换取P,这是目前分布式数据库产品的方向

一致性与可用性的决择?

对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地
1.数据库事务一致性需求
  很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低, 有些场合对写一致性要求并不高。允许实现最终一致性。

2.数据库的写实时性和读实时性需求
  对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

3.对复杂的SQL查询,特别是多表关联查询的需求
  任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

CAP理论的核心是:
一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,
最多只能同时较好的满足两个。
因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP - 满足一致性,分区容忍必的系统,通常性能不是特别高。
AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

BASE

是什么?

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写:
基本可用(Basically Available)
软状态(Soft state)
最终一致(Eventually consistent)

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法

经典应用

在这里插入图片描述

参考资料:周阳Redis讲解

本文若有错误请指正,互相学习,加油!

### 分布式系统中解决一致性问题的方法 在分布式系统中,解决一致性问题是核心挑战之一。为了应对这一挑战,通常采用多种策略和技术手段。 #### 1. CAP 原理概述 CAP定理指出,在一个分布式计算环境中,不可能同时满足以下三个需求: - **一致性 (Consistency)**:所有节点在同一时间拥有相同的数据副本。 - **可用性 (Availability)**:每次请求都能收到响应,不论成功或失败。 - **分区容忍性 (Partition Tolerance)**:即使遇到任意数量的消息丢失或部分故障的情况下仍能继续操作[^1]。 由于分区容忍性几乎是现代互联网应用不可或缺的需求,因此实际上是在一致性和可用性之间做出权衡。 #### 2. ACID 和 BASE 的对比 传统的事务处理遵循ACID原则——原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),这四个属性共同确保了单机环境下数据库交易的安全可靠执行。然而,在大规模分布式的背景下,严格遵守ACID可能会极大地影响系统的性能与伸缩能力。 相比之下,BASE理论则提出了另一种思路: - **基本上可用(Basically Available, BA)**:即便某些组件失效,整个服务仍然能够对外提供最基本的服务功能; - **软状态(Soft State, SS)**:允许存在短暂的时间窗口期内各节点间数据不同步的现象; - **最终一致性(Eventual Consistency, EC)**:经过一定延迟之后,所有的更新都会传播至全部节点并达成全局一致的状态[^2]。 这种模式更适合于那些对实时性强求不高但追求极致用户体验的应用场景。 #### 3. 实现最终一致性的具体措施 为了实现最终一致性,常见的做法包括但不限于: - 使用异步复制机制代替同步提交确认流程; - 引入版本号或者向量时钟来追踪对象的历史变更记录; - 设计幂等接口以防止重复消息造成逻辑错误; - 应用补偿型事务模型处理跨多个资源管理器的操作序列。 ```python def apply_eventually_consistent_update(data_store, key, value): try: data_store[key].append(value) # 添加新值而不是覆盖旧值 except KeyError: data_store[key] = [value] # 示例调用 data_storage = {} apply_eventually_consistent_update(data_storage, 'item', 'new_value') print(data_storage) ``` 上述代码展示了如何在一个简单的字典结构上实施增量式的更新方式,从而支持多源并发写入的同时保持历史信息完整无损。 ### 结合ACID与BASE的设计考量 值得注意的是,并不是所有的业务场景都适合单纯依赖BASE理念构建;相反地,很多情况下还需要兼顾一定的强一致性保障。比如金融支付领域就更倾向于优先考虑安全性而非即时反馈速度。所以在实际项目开发当中,应当依据特定应用场景的具体特征灵活调整设计方案,合理分配各个模块所应具备的一致性级别[^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值