分布式事务Seata【二】CAP定理和Base定理

简介: CAP原则又叫CAP定理,同时又被称作布鲁尔定理(Brewer's theorem)

CAP定理

CAP原则又叫CAP定理,同时又被称作布鲁尔定理(Brewer's theorem),指的是在一个分布式系统中,不可能同时满足以下三点

image.png

  • 一致性(Consistency 副本最新):指强一致性,在写操作完成后开始的任何读操作都必须返回该值,或者后续写操作的结果。

    也就是说,在一致性系统中,一旦客户端将值写入任何一台服务器并获得响应,那么之后client从其他任何服务器读取的都是刚写入的数据

    一致性保证了不管向哪台服务器写入数据,其他的服务器能实时同步数据

  • 可用性(Availability 高可用):可用性是指,每次向未崩溃的节点发送请求,总能保证收到响应数据(允许不是最新数据)

什么是分区?
在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因,这些子节点之间出现了网络不通的状态,但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域。这就是分区。

  • 分区容忍性(Partition tolerance 能容忍网络分区):分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,也就是说,服务器A和B发送给对方的任何消息都是可以放弃的,也就是说A和B可能因为各种意外情况,导致无法成功进行同步,分布式系统要能容忍这种情况。除非整个网络环境都发生了故障。

    image.png

    容许节点 G1/G2 间传递消息的差错(延迟或丢失),而不影响系统继续运行。

    以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

为什么只能在A和C之间做出取舍?

分布式系统中,必须满足 CAP 中的 P,此时只能在 C/A 之间作出取舍。

整个系统由两个节点配合组成,之间通过网络通信,当节点 A 进行更新数据库操作的时候,需要同时更新节点 B 的数据库(这是一个原子的操作)。

下面这个系统怎么满足 CAP 呢?我们用反证法 假设可以同时满足一致性、可用性、分区容错这三个特性,由于满足分区容错,可以切断 A/B 的连线,如下图:

image.png

可见,根本完成不了,只要出现了网络分区,A 就无法满足,因为节点 A 根本连接不上节点 B。如果强行满足 C 原子性,就必须停止服务运行,从而放弃可用性 C。

  • 若要保证一致性:则必须进行节点间数据同步,同步期间数据锁定,导致期间的读取失败或超时,破坏了可用性;
  • 若要保证可用性:则不允许节点间同步期间锁定,这又破坏了一致性。

所以,最多满足两个条件:

组 合 分析结果
CA 满足原子和可用,放弃分区容错。说白了,就是一个整体的应用。
CP 满足原子和分区容错,也就是说,要放弃可用。当系统被分区,为了保证原子性,必须放弃可用性,让服务停用。
AP 满足可用性和分区容错,当出现分区,同时为了保证可用性,必须让节点继续对外服务,这样必然导致失去原子性。

如何权衡(保C还是保A?)

取舍

  • 舍弃P(选择C/A):单点的传统关系型数据库 DBMS(MySQL/Oracle),但如果采用集群就必须考虑P了;
  • 舍弃A(选择C/P):是分布式系统要保证P,而且保证一致性,如 MongoDB / HBase;
  • 舍弃C(选择A/P):是分布式系统要保证P,而且保证可用性,如 CoachDB / Cassandra / DynamoDB。
  • 注:redis-cluster是AP,zookeeper写入强一致,读取是顺序一致性(即弱一致)。

对于一个分布式系统来说,CAP三者中,

  • P是基本要求,只能通过基础设施提升,无法通过降低 C/A 来提升;
  • 然后在 C/A 两者之间权衡。

一个还不错的策略是:保证可用性和分区容错,舍弃强一致性,但保证最终一致性,比如一些高并发的站点(秒杀、淘宝、12306)。最终近似于兼顾了三个特性。

数据一致性

一致性可以分为强一致性与弱一致性。所谓强一致性,即复制是同步的,弱一致性,即复制是异步的。

CAP回顾
CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言,我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是,所谓的“牺牲一致性”并不是完全放弃数据一致性,而是牺牲强一致性换取弱一致性

强一致性

系统中的某个数据被成功更新后,后续任何对该数据的读取操作都将得到更新后的值;

也称为:原子一致性(Atomic Consistency)线性一致性(Linearizable Consistency)

两个要求:

  • 任何一次读都能读到某个数据的最近一次写的数据。
  • 系统中的所有进程,看到的操作顺序,都和全局时钟下的顺序一致。

简言之,在任意时刻,所有节点中的数据是一样的。例如,对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。

总结:

  • 一个集群需要对外部提供强一致性,所以只要集群内部某一台服务器的数据发生了改变,那么就需要等待集群内其他服务器的数据同步完成后,才能正常的对外提供服务。
  • 保证了强一致性,务必会损耗可用性。

弱一致性

系统中的某个数据被更新后,后续对该数据的读取操作可能得到更新后的值,也可能是更改前的值。

但即使过了不一致时间窗口这段时间后,后续对该数据的读取也不一定是最新值

所以说,可以理解为数据更新后,如果能容忍后续的访问只能访问到部分或者全部访问不到,则是弱一致性。

最终一致性

是弱一致性的特殊形式,存储系统保证在没有新的更新的条件下,最终所有的访问都是最后更新的值。

不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化。

简单说,就是在一段时间后,节点间的数据会最终达到一致状态。

一致性总结

弱一致性即使过了不一致时间窗口,后续的读取也不一定能保证一致,而最终一致过了不一致窗口后,后续的读取一定一致

image.png

Base理论

  • BA:Basic Available(基本可用)

    • 整个系统在某些不可抗力的情况下,仍然能够保证“可用性”,即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是:

      • “一定时间”可以适当延长
        当举行大促时,响应时间可以适当延长
      • 给部分用户返回一个降级页面
        给部分用户直接返回一个降级页面,从而缓解服务器压力。但要注意,返回降级页面仍然是返回明确结果。
  • S:Soft State(柔性状态)
    是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统不同节点的数据副本之间进行数据同步的过程存在延时。
  • E:Eventual Consisstency(最终一致性):
    同一数据的不同副本的状态,可以不需要实时一致,但一定要保证经过一定时间后仍然是一致的。

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

目录
相关文章
|
2月前
|
SQL NoSQL 数据库
SpringCloud基础6——分布式事务,Seata
分布式事务、ACID原则、CAP定理、Seata、Seata的四种分布式方案:XA、AT、TCC、SAGA模式
SpringCloud基础6——分布式事务,Seata
|
22天前
|
缓存 Java 数据库
JAVA分布式CAP原则
JAVA分布式CAP原则
44 0
|
3月前
|
关系型数据库 MySQL 数据库
SpringCloud2023中使用Seata解决分布式事务
对于分布式系统而言,需要保证分布式系统中的数据一致性,保证数据在子系统中始终保持一致,避免业务出现问题。分布式系统中对数据的操作要么一起成功,要么一起失败,必须是一个整体性的事务。Seata简化了这个使用过程。
81 2
|
3月前
|
Java 关系型数据库 MySQL
(二十七)舞动手指速写一个Seata-XA框架解决棘手的分布式事务问题
相信大家对于事务问题都不陌生,在之前《MySQL事务篇》中曾详解过MySQL的事务机制,在传统的单库环境下开发,咱们可依赖于MySQL所提供的事务机制,来确保单个事务内的一组操作,要么全部执行成功,要么全部执行失败。
|
4月前
|
算法 前端开发
|
3月前
|
Java Nacos Docker
"揭秘!Docker部署Seata遇上Nacos,注册成功却报错?这些坑你不得不防!一网打尽解决秘籍,让你的分布式事务稳如老狗!"
【8月更文挑战第15天】在微服务架构中,Nacos搭配Seata确保数据一致性时,Docker部署Seata后可能出现客户端连接错误,如“can not connect to services-server”。此问题多由网络配置不当、配置文件错误或版本不兼容引起。解决策略包括:调整Docker网络设置确保可达性;检查并修正`file.conf`和`registry.conf`中的Nacos地址和端口;验证Seata与Nacos版本兼容性;修改配置后重启服务;参考官方文档和最佳实践进行配置。通过这些步骤,能有效排除故障,保障服务稳定运行。
194 0
|
3月前
|
存储 NoSQL 关系型数据库
(二)漫谈分布式之理论篇:用刁钻的手法掰正你那学歪的CAP与BASE理论!
大多数讲分布式的资料、课程,虽然在一开始就会先讲述CAP理论,但大家仔细想想,你在做分布式项目时,落地过这个基础理论吗?相信包括我在内,以及90%以上的开发者,没有,至于为何,本文来从不一样的角度好好唠唠CAP,以及另一个著名的BASE理论~
|
4月前
|
缓存 搜索推荐 Java
Java面试题:简述CAP理论及其在分布式系统设计中的应用。请提供一个具体的例子,说明在系统设计中如何取舍一致性和可用性
Java面试题:简述CAP理论及其在分布式系统设计中的应用。请提供一个具体的例子,说明在系统设计中如何取舍一致性和可用性
49 0
|
5月前
|
缓存 NoSQL 数据库
分布式系统面试全集通第一篇(dubbo+redis+zookeeper----分布式+CAP+BASE+分布式事务+分布式锁)
分布式系统面试全集通第一篇(dubbo+redis+zookeeper----分布式+CAP+BASE+分布式事务+分布式锁)
102 0
|
5月前
|
存储 关系型数据库 Java
技术经验解读:三种分布式事务LCN、Seata、MQ
技术经验解读:三种分布式事务LCN、Seata、MQ
165 0