# base-message-list-cloud-simple

**Repository Path**: java-233/base-message-list-cloud-simple

## Basic Information

- **Project Name**: base-message-list-cloud-simple
- **Description**: Springcloud <!-跨服务>本地消息表分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用mysql进行本地消息表进行处理分支事务
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2024-02-05
- **Last Updated**: 2024-02-05

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# base-message-list-cloud-simple

#### 介绍
Springcloud <!-跨服务>本地消息表分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用mysql进行本地消息表进行处理分支事务
本地消息表是最终一致性解决方案,BASE原理,保持事务最终一致,允许在一段时间内不一致但最终会一致


#### 业务
 - base-message-list-cloud-pay:支付微服务
 - base-message-list-cloud-order:订单微服务
 - 订单已存在但状态是未支付状态(模拟加入购物车之后支付取消,但订单依然存在,再次进行支付 进行 扣减账户余额 生成支付消息数据 修改订单状态)
 - RPC远程调用【订单微服务】如果没有执行成功,【支付微服务】会每10秒中扫描一次本地消息列表重新进行调用【订单微服务】修改状态直到修改成功,超过5次不成功进行报警通知相关人员进行手动补偿
 
 - 基于本地消息表的方案中，将本事务外操作，记录在消息表中
 - 其他事务，提供操作接口
 - 定时任务轮询本地消息表，将未执行的消息发送给操作接口。
 - 操作接口处理成功，返回成功标识，处理失败，返回失败标识。
 - 定时任务接到标识，更新消息的状态
 - 定时任务按照一定的周期反复执行
 - 对于屡次失败的消息，可以设置最大失败次数(本例设置3次,定时采用多线程方式提高效率)
 - 超过最大失败次数的消息，不进行接口调用
 - 报警等待人工补偿

![本地消息表事务](https://images.gitee.com/uploads/images/2020/1204/170457_ae374b12_1520293.jpeg "本地消息表分布式事务.jpg")

#### 技术选型
 - SpringBoot
 - Mybatis
 - Logback
 - Hikari
 - Mysql(5.7.2.0)
 - SpringCloud(Greenwich)
 - Eureka
 - openFeign
 - Hystrix
 - Gateway(动态路由)

#### 数据库
 - 在mysql中建立以下2个库，然后在对应库中导入base-message-list-cloud-common/resources/数据库表结构 对应的表
 - ml_order/订单库 3308
 - ml_pay/支付库 3307
 - 没有多数据源条件就直接分库建立


#### 注意点
 - 该项目为多模块微服务，各微服务之间数据源隔离独立，且单个服务可自行选择分布式事务和多数据源配置方式
 - 本项目为本地消息列表分布式事务脚手架不考虑其他因素（如：锁、多线程等等）
 
#### 项目启动顺序
 - 启动Eureka注册中心: base-message-list-cloud-eureka-server (访问注册中心地址: http://localhost:19079/)
 - 启动Gateway网关路由: base-message-list-cloud-gateway-server
 - 启动支付微服务: base-message-list-cloud-pay
 - 启动订单微服务: base-message-list-cloud-order
 
#### 测试
 - 查看gateway网关下的测试用例.md进行请求网关
 - 也可以查看支付微服务下的测试用例.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）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
 
  - 软状态
     软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
 
  - 最终一致性
     最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。