# springboot+mybatis+dubbo+nacos+seata

**Repository Path**: Easettle/seata-sample

## Basic Information

- **Project Name**: springboot+mybatis+dubbo+nacos+seata
- **Description**: springboot+mybatis+dubbo+nacos+seata-- demo
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-01-01
- **Last Updated**: 2022-01-06

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# springboot+mybatis+dubbo+nacos+seata---  分布式事务
##CAP理论
CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：
一致性（Consistency）在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。
可用性（Availability）一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。
分区容错性（Partition tolerance）指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的 (不继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了)
最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CA
CAP三者不可兼得，该如何取舍：
(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
(3) AP: 优先保证可用性和分区容错性，放弃一致性。NoSQL中的Cassandra 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。
##BASE理论
BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。
基本可用（Basically Available）
    什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
    响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
    功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态（Soft State）    
    什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
    软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性（Eventually Consistent）
    上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
     而在实际工程实践中，最终一致性分为5种：
     3.3.1. 因果一致性（Causal consistency）
     因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
     3.3.2. 读己之所写（Read your writes）
     读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
     3.3.3. 会话一致性（Session consistency）
     会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
     3.3.4. 单调读一致性（Monotonic read consistency）
     单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
     3.3.5. 单调写一致性（Monotonic write consistency）
     单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。     
     在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。
     实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。   
     
##seata
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
Seata的模块组成
1）TM：事务发起者。定义事务的边界，负责告知 TC，分布式事务的开始，提交，回滚。
2）RM：资源管理者。管理每个分支事务的资源，每一个 RM 都会作为一个分支事务注册在 TC。
3）TC ：事务协调者。负责我们的事务ID的生成，事务注册、提交、回滚等。
在Seata的AT模式中，TM和RM都作为SDK的一部分和业务服务在一起，我们可以认为是Client。TC是一个独立的服务，通过服务的注册、发现将自己暴露给Client们。
#1.AT模式

#2.TCC模式
TCC（Try-Confirm-Cancel）是一种比较成熟的分布式数据一致性解决方案，它实际上是把一个完整的业务拆分为如下三个步骤。
    1.Try：这个阶段主要是对数据的校验或者资源的预留
    2.Confirm：确认真正咨询的任务，只操作Try阶段预留的资源
    3.Cancel：取消咨询，释放Try阶段预留的资源
需要注意 TCC服务支持接口调用失败发起重试。所以TCC暴露的接口都需要满足幂等性    
#3.Saga模式



##模块介绍
    1.sample-order-service ----   订单服务
    2.sample-repo-service  ----   库存服务      
    3.sample-account-service ---- 账户服务
    4.sample-seata-common  ----   公共组件服务
    5.sample-rest-web      ----   提供统一业务的Rest接口服务

实现功能场景
    1.下单扣库存、订单写表、账户余额扣减--事物一致

 sql文件和需要用到的中间键
 链接：https://pan.baidu.com/s/1TcVOtvJF2zkNCSxX-8wcIg 
 提取码：zrkx