标签：事务 数据库 可用性 谷粒 提交 一致性 商城 分布式
事务
本地事务
什么是事务
事务：通俗的来讲就是我们做一件事情中间分为每个小步骤，只有所有步骤完成这件事情才算完成。
事务四大特性
原子性：指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性：事务必须使数据库从一个一致性状态变换到另外一个一致性状态。转账前和转账后的总金额不变。
隔离性：事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性：指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。
事务的隔离级别
Read uncommitted(读未提交)：一个事务可以读取另一个未提交事务的数据。
举例：数据库中字段price为1000，A修改数据库为1500，此时B查看price为1500，结果A回滚了事务，数据库中数据还是1000。
结果：B出现脏读
Read committed(读已提交)：一个事务要等另一个事务提交后才能读取数据。（针对的是UPDATE操作）
举例：数据库中字段price为1000，A查看数据为1000，告诉了C，此时B将数据进行了修改，修改为1600，当C去查看price为1600。
结果：出现了不可重复读现象
Repeatable read(可重复读)：读取多条记录时，同一事务两次读取的数据条数不一致。在一条记录上的操作是，不能读取已由其它事务修改了但是未提交的行，其它任何事务也不能修改在当前事务完成之前由当前事务读取的数据。
举例：数据库中只有一条记录，当A查看时只有一条，A告诉C，此时B去数据库插入一条数据，C去查看时有两条。
结果：出现了幻读现象
Serializable (序列化):事务串行化顺序执行，可以避免脏读、不可重复读与幻读。
MYSQL隔离级别：可重复读
Oracle隔离级别：读已提交
事务传播行为
事务的传播行为：想要发生传播就一定要有两个以上的物体，而这里指的是两个方法都要在事务中进行，当一个事务方法A调用另一个事务方法B时，另一个事务方法B该如何运行。
Spring一共定义了7种事务传播行为（事务方法B该如何运行）：
本地事务@Transactional+传播行为
//事务使用代理对象来控制
@Transactional(timeout = 10)
public void A(){
//b,c做任何设置都没作用，都是和A公用一个事务,此时不生效，要使用代理
B();
C();
}
// 此时如果A有事务，就使用A的事务，A没有事务，就新建事务
@Transactional(propagation = Propagation.REQUIRED,timeout = 5)
public void B(){
}
// 不和A公用一个事务，新建事务
@Transactional(propagation = Propagation.REQUIRES_NEW,timeout = 20)
public void C(){
}
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++
本地事务失效问题：
同一个对象内事务方法互调默认失效，原因 绕过了代理对象，事务使用代理对象来控制的
解决：使用代理对象来调用事务方法
针对：本类方法互调使用事务
1）引入spring-boot-starter-aop；引入aspectj
2）主启动类@EnableAspectJAutoProxy(exposeProxy = true)；
开启aspectj动态代理功能。以后所有的动态代理都是aspectj创建的（即使没有接口也可以创建动态代理）。
对外暴露代理对象
3）用代理对象本类互调
使用：OrderService orderService = AopContext.currentProxy(); orderService.b(); orderService.c();
@Transactional(timeout = 10)
public void A(){
//b,c做任何设置都没作用，都是和A公用一个事务,此时不生效，要使用代理
OrderServiceImpl orderService = (OrderServiceImpl) AopContext.currentProxy();
orderService.B();
orderService.C();
}
分布式事务
分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。
分布式事务产生的场景
分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。
分布式经常出现的异常：机器宕机，网络异常，消息丢失，消息乱序，数据错误，不可靠的TCP，存储数据丢失。。。
CAP理论
C：Consistency（强一致性）
A：Availability（可用性）
P：Partition tolerance（分区容错性）
CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP-满足一致性，分区容错的系统，通常性能不是特别高。
AP-满足可用性，分区容错的系统，通常对一致性要求略低一些。
在当前分布式的大环境中，P已经成为必不可少！！！
当前主流技术对CAP的使用：
必然会接触到分布式系统，例如：zookeeper就是使用CP原则，eureka使用AP原则
AP架构
CP架构
分布式中实现强一致性的raft算法:
详解：尚硅谷谷粒商城285集
CP
http://thesecretlivesofdata.com/raft/
面临的问题：
对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99…%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。
BASE理论
BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终一致性。满足BASE理论的事务，我们称之为“柔性事务”。
Base理论介绍
基本可用（Basically Available）:基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
- 响应时间上的损失：正常情况下搜索引擎需要在0．5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1～2秒。
- 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态（Soft state）:软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
最终一致性（Eventual Consistency）: 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。（这也是分布式事务的想法）
从客户端角度，多进程并发访同时，更新过的数据在不同程如何获的不同策珞，决定了不同的一致性。 - 对于关系型要求更新过据能后续的访同都能看到，这是强一致性。
- 如果能容忍后经部分过者全部访问不到，则是弱一致性
- 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性
分布式事务解决方案
针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。
2PC(两阶段提交)
数据库支持的2PC【二阶段提交】，又被称为XA Transactions
Mysql从5.5开始支持，SQL Server 2005开始支持，Oracle 7开始支持。
其中XA是一个两阶段提交协议：
第一阶段为 准备（prepare）阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。
第二阶段为提交阶段（commit）。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
其中如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们在此事务中的那部分信息
优缺点：
- XA协议比较简单，商业数据库使用，使用分布式事务的成本低。
- XA性能不理想，特别是交易下单链路，往往并发量很高，XA无法满足高并发场景。
- XA在商业数据库支持比较理想，在mysql数据库支持不太理想，MYSQL的XA实现没有记录prepare阶段日志，主备切换导致主库和备库数据不一致。
- 也有3PC，引入超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理）
TCC（柔性事务）
刚性事务：遵循ACID原则，强一致性。
柔性事务：遵循BASE理论，最终一致性。
TCC 模式，不依赖于底层数据资源的事务支持：
一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
二阶段 commit 行为：调用 自定义 的 commit 逻辑。
二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
可靠消息最终一致性（柔性事务）
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，**事务参与方(消息消费者)一定能够接收消息并处理事务成功，**此方案强调的是只要消息发给事务参与方最终事务要达到一致。
最大努力通知（柔性事务）
按规律进行通知，不保证数据一定能通知成功，但是会提供可查询操作接口进行核对。
用途：用在与第三方进行通讯时，如：微信支付宝支付后的支付结果通知。结合MQ进行实现，通过MQ发送http请求，设置最大通知次数，次数到达就不通知。
案例：银行通知，商户通知，支付宝支付成功异步回调。
标签：事务,数据库,可用性,谷粒,提交,一致性,商城,分布式 来源： https://blog.csdn.net/weixin_45873488/article/details/120326063
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。