目录
1.1 什么是事务
1.1 什么是事务
-
概述
-
数据库事务（简称：事务，Transcation）是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成【由当前业务逻辑多个不同操作构成】
-
-
事务拥有以下四个特性，习惯上被称为ACID特性：
-
原子性（Atomicity）
-
事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行
-
付款收款要么一起执行成功，要么一起执行失败
-
-
-
一致性（Consistency）
-
事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另一层语义，就是事务的中间状态不能被观察到（这层语义也有说应该属于原子性）
-
付款收款付款多少，收款就有多少
-
-
-
隔离性（Isolation）
-
多个事务并发执行时，一个事务的执行不应该影响其它事务的执行，如同只有这一个操作在被数据库所执行一样
-
多个抢票事务同时开始，互相之间不影响其它抢票事务的执行，各抢各的
-
-
-
持久性（Duriability）
-
已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作不可逆转
-
付款收款一旦双方都执行成功持久化到了数据库，n那么数据库中的数据就不可回滚
-
-
-
1.2 本地事务
1.2什么是本地事务
-
概述
-
起初，事务仅限于对于单一数据库资源的访问控制，架构服务化以后，事务的概念就延伸到了服务中，倘若将一个单一的服务操作作为一个事物，那么整个服务操作只能涉及一个单一的数据库资源，这类基于单个服务单一数据库资源访问的事务，被称为本地事务（Local Transaction）
-
1.3 什么是分布式事务
1.3 什么是分布式事务
-
概述
-
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上说，分布式事务就是为了保证不同数据库的数据一致性
-
1.4 分布式事务应用架构
1.4 分布式事务应用架构
-
概述
-
本地事务主要限制在单个会话内，不涉及多个数据库资源。但是在基于SOA(Service-Oriented Architecture，面向服务架构）的分布式应用环境下，越来越多的应用要求对多个数据库资源，多个服务的访问都能纳入到同一个事务当中，分布式事务应运而生
-
-
1.4.1 单一服务分布式事务
-
最早的分布式服务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作设计到对多个数据库资源的访问
-
-
1.4.2 多服务分布式事务
-
当一个服务操作访问不同的数据库资源，又希望对他们的访问具有事物特性时，就需要采用分布式事务来协调所有的事务参与者。
-
对于前面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟好着呢哥哥事务还是控制在一个单一服务的内部。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一个服务，从而使被调用的服务访问的资源也自动假如到该事务当中来。
-
-
1.4.3 多服务多数据源分布式事务
-
如果将上面这两种场景（一个服务可以调用多个数据库资源，也可以调用其他服务）结合在一起，对此进行延伸，整个分布式事务的参与者将会组成一个树形拓扑结构。在一个跨服务的分布式事务中，事务的发起者和提交者均系同一个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服务
-
较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂，在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变
-
-
1.4.4 事务的作用：
-
保证每个事务的数据一致性。
-
1.5 CAP定理
概述
-
CAP定理，又被叫做布鲁尔定理。对于设计分布式系统（不仅仅是分布式事务）的架构师来说，CAP就是你的入门理论
C (一致性)
-
对于某个指定的客户端来说，读操作能返回最新的写操作
-
对于数据分布在不同节点上的数据来说，如果在某个节点更新了数据，name在其他节点如果都能读取到这个最新的数据，name就称为强一致，如果有某个节点没有读取到，那就是分布式不一致
A (可用性)
-
非故障的节点在合理的时间内返回合理的相应（不是错误和超时的响应）。可用性的两个关键一个是合理的时间，一个是合理的响应
-
合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的。
P (分区容错性)
-
当出现网络分区后，系统能够继续工作。打个比方，这里集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
-
熟悉 CAP 的人都知道，三者不能共有，如果感兴趣可以搜索 CAP 的证明，在分布式系统中，网络无法 100% 可靠，分区其实是一个必然现象。
-
如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是 A 又不允许，所以分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
-
对于 CP 来说，放弃可用性，追求一致性和分区容错性，我们的 ZooKeeper 其实就是追求的强一致。
-
对于 AP 来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的 BASE 也是根据 AP 来扩展。
-
顺便一提，CAP 理论中是忽略网络延迟，也就是当事务提交时，从节点 A 复制到节点 B 没有延迟，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。
-
同时 CAP 中选择两个，比如你选择了 CP，并不是叫你放弃 A。因为 P 出现的概率实在是太小了，大部分的时间你仍然需要保证 CA。
-
就算分区出现了你也要为后来的 A 做准备，比如通过一些日志的手段，是其他机器回复至可用。
注：（name：那么）；
/*博主本人也在学习中，有不对的地方或者还请评论指出或者Call me 私信都可*/
/*下一篇：分布式事务解决方案https://blog.csdn.net/qq_40629687/article/details/119892811*/
7809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
