# tx-lcn-2pc-cloud-simple

**Repository Path**: FangHuaiMing/tx-lcn-2pc-cloud-simple

## Basic Information

- **Project Name**: tx-lcn-2pc-cloud-simple
- **Description**: Springcloud <!-跨服务>TX-LCN分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2020-11-29
- **Last Updated**: 2022-10-25

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# tx-lcn-2pc-cloud-simple

#### 介绍
Springcloud
Springcloud <!-跨服务>TX-LCN分布式事务(分布式事务交易框架)/使用spring-cloud 各个数据源在细粒度化微服务本身

#### 技术选型
 - SpringBoot
 - Mybatis
 - Logback
 - Hikari
 - Mysql(5.7.2.0)
 - SpringCloud(Greenwich)
 - Eureka
 - openFeign
 - Hystrix
 - Gateway(动态路由)
 - LCN(5.0.2.RELEASE)将Lcn全局事务保存在lcn_manager数据库,自身配置及其通讯使用redis
 - Redis(6.0.9)

#### 数据库
 - lcn_order/订单库 3306
 - lcn_item/商品库存 3307
 - lcn_account/账户库 3308
 - lcn_manager/TM数据库 3309

#### 业务
 - 用户下订单（插入数据DDL）
 - 扣减库存sku（更新数据DDL）
 - 扣减账户余额（更新数据DDL）
 
#### 注意点
 - 该项目为多模块微服务，各微服务之间数据源隔离独立，且单个服务可自行选择分布式事务和多数据源配置方式
 - 本项目为lcn分布式事务脚手架不考虑其他因素（如：锁、多线程等等）
 - 数据库方面,如果条件不允许就使用同一个Mysql创建不同的库也可以,数据库不同库事务隔离
 
#### 项目启动顺序
 - 启动Eureka注册中心: tx-lcn-2pc-cloud-eureka-server (访问注册中心地址: http://localhost:19079/)
 - 启动Gateway网关路由：tx-lcn-2pc-cloud-gateway-server
 - 启动Redis
 - 启动tx-lcn-2pc-cloud-tm（访问地址:http://127.0.0.1:7970/admin/index.html#/login）默认密码:fanghuaiming
 - 启动订单微服务: tx-lcn-2pc-cloud-order
 - 启动商品微服务: tx-lcn-2pc-cloud-item
 - 启动账户微服务: tx-lcn-2pc-cloud-account
 - 各个微服务自己就是TC,tx-lcn-2pc-cloud-tm就是TM,基于Redis通讯而未使用eureka
 
#### 测试
 - 注释com.fanghuaiming.lcn.order.service.impl.OrderServiceImpl.placeOrder的@GlobalTransactional访问下订单造成异常查看数据库是否自动回滚
 - 打开注释进行测试查看是否回滚
 
 
 
 # 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）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

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

 - 最终一致性
    最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。