# dtx-tcc-hmily-cloud-simple

**Repository Path**: FangHuaiMing/dtx-tcc-hmily-cloud-simple

## Basic Information

- **Project Name**: dtx-tcc-hmily-cloud-simple
- **Description**: Springcloud <!-跨服务>Hmily-TCC分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用Hmily实现Try-Confirm-Cancel
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2020-12-02
- **Last Updated**: 2021-07-26

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# dtx-tcc-hmily-cloud-simple

#### 介绍
Springcloud <!-跨服务>Hmily-TCC分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用Hmily实现Try-Confirm-Cancel


Hmily访问地址 : https://github.com/Dromara/hmily

![Hmily](https://images.gitee.com/uploads/images/2020/1202/143028_f0c28be0_1520293.png "hmily.png")

![HmilyTcc](https://images.gitee.com/uploads/images/2020/1202/143042_f0d51faf_1520293.png "hmilytcc.png")

#### 业务
 - dtx-tcc-hmily-cloud-aboc进行转转到dtx-tcc-hmily-cloud-icbc
 - dtx-tcc-hmily-cloud-aboc进行扣款TCC
 - dtx-tcc-hmily-cloud-icbc进行转账收款TCC

| 业务  | Try  | Confirm  |  Cancel |
|---|---|---|---|
| 账户A转帐给账户B  |  检查余额是否够30元 | 空  | 增加30元  |
| 账户A接受账户B转帐  |  增加30元 |  空 |  减少30元 |

实际解决业务方案

| 业务  | Try  | Confirm  |  Cancel |
|---|---|---|---|
| 账户A转帐给账户B  |  try幂等校验、try悬挂处理、检查余额是否够30元、扣减30元 | 空  | cancel幂等校验、cancel空回滚处理、增加可用余额30元  |
| 账户A接受账户B转帐  |  空 |  confirm幂等校验、正式增加30元 |  空 |


![业务表](https://images.gitee.com/uploads/images/2020/1203/105834_0922f268_1520293.png "yewu.png")

#### 技术选型
 - SpringBoot
 - Mybatis
 - Logback
 - Hikari
 - Mysql(5.7.2.0)
 - SpringCloud(Greenwich)
 - Eureka
 - openFeign
 - Hystrix
 - Gateway(动态路由)
 - Hmily(使用最新发布版本2.0.6的boot-starter,tcc都是异步多线程调用的，事务分散,不锁表,大事务小事务)

#### 数据库
 - 在mysql中建立以下3个库，然后在对应库中导入dtx_tcc-hmily-cloud/common/resources/数据库表结构 对应的表
 - dtx_tcc_aboc/aboc库在 3308
 - dtx_tcc_icbc/icbc库在 3309
 - hmily库 在3307
 - 没有多数据源条件就直接分库建立

 
#### 注意点
 - 该项目为多模块微服务，各微服务之间数据源隔离独立，且单个服务可自行选择分布式事务和多数据源配置方式
 - 本项目为Hmily分布式事务脚手架不考虑其他因素（如：锁、多线程等等）
 
#### 项目启动顺序
 - 启动Eureka注册中心: dtx-tcc-hmily-cloud-eureka-server (访问注册中心地址: http://localhost:19079/)
 - 启动Gateway网关路由: dtx-tcc-hmily-cloud-gateway-server
 - 启动ABOC微服务: dtx-tcc-hmily-cloud-aboc
 - 启动ICBC微服务: dtx-tcc-hmily-cloud-icbc
 - 启动Hmily-Admin（可启可不启,对事务不会有影响,只是为了观察有个控台而已）
 安装包同样在common项目下,也可以自己从github拉取最新分支版本(安装文档 : https://www.bookstack.cn/read/hmily-zh/2.md)
 启动hmily-admin后访问地址: http://localhost:18888/hmily-admin
 
#### 测试
 - 查看gateway网关下的测试用例.md进行请求网关
 - 也可以查看ABOC微服务下的测试用例.md进行请求微服务(正例测试、反例测试)
 
 
  # CAP定律
     这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
 
  - 一致性（C）
     在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
 
  - 可用性（A）
     在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
 
  - 分区容错性（P）
     以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
 
 # BASE理论
     BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
 
  - 基本可用
     基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—-注意，这绝不等价于系统不可用。比如：
 
 （1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
 
 （2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
 
  - 软状态
     软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
 
  - 最终一致性
     最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。