1.事务

1.1 事务的4个特性 ACID

1.1.1. 原子性(要么执行，要么不执行)

原子性(Atomicity):操作这个指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回滚到指令前的数据状态

1.1.2. 一致性(能量守恒，总量不变)

事务的执行使数据从一个状态转化为另一个状态，数据的完整性约束没有被破坏

1.1.3 隔离性 (信息彼此独立,互不干扰)

隔离性是当多个用户并发访问数据库时，如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离

1.1.4 持久性 (不会轻易丢失)

当事务正确完成后，它对于数据的改变是永久性的

2. CAP原理

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

2.1 一致性(副本最新)

指强一致性在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取到的都是刚写入的数据(一致性保证了不管向哪台服务器写入数据其他的服务器都能及时的同步数据)

2.2 可用性(高可用)

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

2.2.1 什么是分区

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

2.3 分区容忍性

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

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

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

因而最对只能满足两个条件

组合	分析结果
CA	满足原子和可用放弃分区容错->单体应用
CP	满足原子和分区容错也就是要放弃可用当系统被分区为了保证原子性就必须要放弃可用性让服务停用
AP	满足可用性和分区容错当出现分区，同时为了保证可用性，必须让节点继续对外服务，这样必然会失去原子性

2.4 如何权衡保证C还是A?

2.4.1 取舍

舍弃P(选择C/A):单点的传统关系型数据库DBMS(Mysql/Oracle)
，但如果是集群就必须要考虑P了
舍弃A(选择C/P):是分布式系统要保证P，而且保证一致性如:zookeeper/Redis/MongoDB/HBase
舍弃C(选择A/P):是分布式系统要保证P，而且保证可用性如CoachDB/Cassandra/DynamoDB

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

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

一个还不错的策略是:保证可用性和分区容错，舍弃强一致性，但保证最终一致性如12306 等都会近似兼顾三个特性

2.5 一致性(数据一致性)

一致性可以分为强一致性和弱一致性。所谓强一致性即复制是同步的，弱一致性即复制是异步的(所谓牺牲一致性并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性)

2.5.1 强一致性

系统中的某个数据成功更新后后续任何对该数据的读取操作都将得到更新后的值也称为:原子一致性线性一致性

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

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

总结:

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

2.5.2 弱一致性

系统中的某个数据被更新后，后续对该数据操作可能得到的是更新后的值，也可能得到的是更新前的值但即使过了 “不一致时间窗口” 这段时间后续对该数据的读取也不一定是最新的(数据更新后，如果能容忍后续只能访问到部分或者访问不到则为弱一致性)

2.5.3 最终一致性

是弱一致性的特殊形式，存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值。不保证在任意节点上的同一份数据都是相同的,但是随着时间的迁移，不同节点上的同一份数据总是在趋同的方向变化(过一段时间后，节点间的数据最终会达到一致状态)

2.5.4 弱一致性和强一致性的区别

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

强制性要求步骤2读取的时候，一定要读取的是2，不能读取到的是1，那么要求数据库之间同步非常迅速或者在步骤2上加锁
等待数据同步完成，那么这就叫强一致性允许步骤2读取的时候，可以读取的是1，那么这种叫弱一致性，其实就是不需要一致性允许步骤2读取的时候，可以先读到1，过一段时间再读到2，那么这就叫最终一致性，就是可以等待一段时间才一致

3.Base理论

3.1 BA: Basic Available(基本可用)

整个系统在某些不可抗力的情况下，仍然能够保证可用性，即一定时间内任然能够返回一个明确的结果。只不过"基本可用"和"高可用"的区别
- "一定时间"可以适当延长当举行大促时响应时间可以适当进行延长
- 给部分用户返回一个降级页面，从而缓解服务器压力。但要注意返回降级页面任然是返回明确结果

3.2 S: Soft State(柔性状态)

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

3.3 E: Eventual Consisstency(最终一致性)

同一数据的不同副本状态，可以不需要实时一致，但一定要保证过了一定时间后任然是一致的

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

4. 分布式事务协议

背景：在分布式系统里，每个节点都可以知晓自己操作的成功或者是失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保证事务的原子性和一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者是回滚

4.1 二阶段提交(2PC)

二阶段提交协议(Two-phase Commit,即 2PC) 是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理

4.1.1 阶段

准备阶段
提交阶段

4.1.2 参与角色

协调者:事务的发起者
参与者:事务的执行者

4.1.3 第一阶段(voting phase 投票阶段)

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复
各参与者执行事务操作，将undo和redo 信息记入事务日志中(但不提交事务)
如果参与者执行成功，给协调者反馈同意，否则反馈中止

4.1.4 第二阶段(commit phase 提交执行阶段)

当协调者节点从所有参与者节点获得的相应消息都为同意时:

协调者节点向所有参与者发出正式提交的请求
参与者节点正式完成操作，并释放在整个事务期间内占用的资源
参与者节点向协调者节点发送ack完成消息
协调者节点收到所有参与者节点反馈的ack完成消息后完成事务

不管结果如何第二阶段都不会结束当前事务

二阶段提交看起来确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的：

性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。
数据一致性问题：二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

4.1.5 二阶段提交的优缺点

优点:尽量保证了数据的强一致，适合对数据强一致要求高的关键领域
缺点:实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景

4.2 三阶段提交(3PC)

三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改动点

在协调者和参与者都引入了超时机制
在第一阶段和第二阶段插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的
也就是说除了引入超时机制之外，3PC吧2PC的准备节点再次一分为二，这样三阶段的提交就有CanCommit、PreCommit、DoCommit三个阶段

分布式事务及分布式事务的解决方案seata相关推荐

分布式事务解决方案Seata
一.Seata 简介 Seata 是阿里巴巴2019年开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务.在 Seata 开源之前,Seata 对应的内部版本在阿里内 ...
分布式事务解决方案Seata——AT模式详解
需要了解分布式事务的同学可以关注我的专栏一起学习,欢迎沟通:分布式事务阿里开源分布式事务一站式解决方案seata基础认识可参见:分布式事务2PC协议之--Seata方案基本认识概述在我的另一篇关 ...
springcloud分布式事务_Springcloud 分布式事务集成Naco Seata
前言:分布式系统架构中,最最费劲的是分布式事务,分布式事务解决方案网上大致分为两种消息一致性基于TCC分布式事务不管基于那种解决方案,都是对侵入的代码植入,以大量的代码或者消息来作为代价,来实现 ...
xa 全局锁_分布式事务如何实现？深入解读 Seata 的 XA 模式
原标题:分布式事务如何实现?深入解读 Seata 的 XA 模式作者简介:煊檍,GitHub ID:sharajava,阿里巴巴中件间 GTS 研发团队负责人,SEATA 开源项目发起人,曾在 Or ...
尚硅谷谷粒商城第六天本地事务、分布式事务及seata
1. 本地事务商品新增功能非常复杂,商品管理微服务在service层中调用保存spu和sku相关的方法,为了保证数据的一致性,必然会使用事务. 在JavaEE企业级开发的应用领域,为了保证数据的完整 ...
分布式事务系列（一）：Seata的AT模式整体流程
微服务架构关于微服务,ThoughtWorks 公司的首席科学家 Martin Fowler 有如下解释: In short, the microservice architectural styl ...
分布式事务及分布式框架Seata
分布式事务 ==分布式事务是什么? ==>本地事务是一个单元的sql,分布式事务也是一个单元的sql,他们区别在于,分布式事务的sql分布在了不同服务上,这里的服务指微服务和数据库服务 ==?为 ...
一致先验分布后验分布_「分布式技术」分布式事务最终一致性解决方案，下篇...
各位志同道合的朋友们大家好,我是一个一直在一线互联网踩坑十余年的编码爱好者,现在将我们的各种经验以及架构实战分享出来,如果大家喜欢,就关注我,一起将技术学深学透,我会每一篇分享结束都会预告下一专题上 ...
分布式事务中的三种解决方案详解(转载)
一.分布式事务前奏快看小说网事务:事务是由一组操作构成的可靠的独立的工作单元,事务具备ACID的特性,即原子性.一致性.隔离性和持久性. 本地事务:当事务由资源管理器本地管理时被称作本地事务.本地事 ...

分布式事务及分布式事务的解决方案seata