# try-best-notify-cloud-simple

**Repository Path**: FangHuaiMing/try-best-notify-cloud-simple

## Basic Information

- **Project Name**: try-best-notify-cloud-simple
- **Description**: Springcloud <!-跨服务>try-best-notify分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用MQ实现最大努力通知分布式事务
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2020-12-03
- **Last Updated**: 2022-01-21

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# try-best-notify-cloud-simple

#### 介绍
Springcloud <!-跨服务>try-best-notify分布式事务/使用spring-cloud 各个数据源在细粒度化微服务本身,使用MQ实现最大努力通知分布式事务


#### 业务
 - try-best-notify-cloud-pay:充值微服务
 - try-best-notify-cloud-account:账户微服务
 - 调用【充值微服务】进行充值
 - 【充值微服务】通过MQ高可用消息通知(持久化失败重试)【账户微服务】
 - 【账户微服务】如果长时间没有执行完自己的事务,会主动查询充值服务

![输入图片说明](https://images.gitee.com/uploads/images/2020/1203/214903_827e47b1_1520293.png "1.png")

![输入图片说明](https://images.gitee.com/uploads/images/2020/1203/214917_05567dab_1520293.png "2.png")

![输入图片说明](https://images.gitee.com/uploads/images/2020/1203/214929_f8e62797_1520293.jpeg "yewu.jpg")

#### 技术选型
 - SpringBoot
 - Mybatis
 - Logback
 - Hikari
 - Mysql(5.7.2.0)
 - SpringCloud(Greenwich)
 - Eureka
 - openFeign
 - Hystrix
 - Gateway(动态路由)
 - RocketMq(4.7.1,该版本在本项目中使用4.7.1以及rocketmq-console使用2.0.0)

#### 数据库
 - 在mysql中建立以下2个库，然后在对应库中导入try-best-notify-cloud-common/resources/数据库表结构 对应的表
 - notify_account/账户库 3306 
 - notify_pay/充值库 3307
 - 没有多数据源条件就直接分库建立


#### 注意点
 - 该项目为多模块微服务，各微服务之间数据源隔离独立，且单个服务可自行选择分布式事务和多数据源配置方式
 - 本项目为最大努力通知分布式事务脚手架不考虑其他因素（如：锁、多线程等等）
 - RocketMq
 
#### 项目启动顺序
 - 启动Eureka注册中心: try-best-notify-cloud-eureka-server (访问注册中心地址: http://localhost:19079/)
 - 启动Gateway网关路由: try-best-notify-cloud-gateway-server
 - 解压try-best-notify-cloud-common/resources/rocketmq/rocketmq-all-4,7.1-source-release.zip
 - 进入解压文件夹中执行`mvn -Prelease-all -DskipTests clean install -U`进行安装
 - 修改runserver.sh/runbroker.sh的jvm启动大小然后分别启动nameserver和broker
 关于以上rocketmq安装请查看连接:http://rocketmq.apache.org/docs/quick-start/
 - 解压ts-ec-rocketmq-cloud-common/resources/rocketmq-console进行解压安装
 关于以上rocketmq-console安装请查看链接:https://github.com/apache/rocketmq-externals
 - 启动账户微服务: try-best-notify-cloud-account
 - 启动充值微服务: try-best-notify-cloud-pay
 
#### 测试
 - 查看gateway网关下的测试用例.md进行请求网关
 - 也可以查看支付微服务下的测试用例.md进行请求微服务
 - 使用RocketMQTemplate整合使用
 
 
  # 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）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
 
  - 软状态
     软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
 
  - 最终一致性
     最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。