Java各类技能知识点学习链接大全：六、SpringCloud_spring cloud alibaba 幂等组件-CSDN博客

（1）在登录验证通过后，给用户生成一个对应的随机token(注意这个token不是指jwt，可以用uuid等算法生成)，然后将这个token作为key的一部分，用户信息作为value存入Redis，并设置过期时间，这个过期时间就是登录失效的时间
（2）将第1步中生成的随机token作为JWT的payload生成JWT字符串返回给前端
（3）前端之后每次请求都在请求头中的Authorization字段中携带JWT字符串
（4）后端定义一个拦截器，每次收到前端请求时，都先从请求头中的Authorization字段中取出JWT字符串并进行验证，验证通过后解析出payload中的随机token，然后再用这个随机token得到key，从Redis中获取用户信息，如果能获取到就说明用户已经登录

JWT详解_baobao555#的博客-CSDN博客_jwt

SpringCloud：Gateway之鉴权_yololee_的博客-CSDN博客_gateway鉴权

spring cloud gateway基于jwt实现用户鉴权+GatewayFilter自定义拦截器（完整demo）_爱学习的老王的博客-CSDN博客_gateway自定义拦截器

14、SpringCloud gateway 静态路由和动态路由：

Spring Cloud Gateway + Nacos 实现动态路由-eolink官网

【SpringCloud】Gateway路由配置（十七） - H__D - 博客园 (cnblogs.com)

Nacos + Spring Cloud Gateway动态路由配置 - 腾讯云开发者社区-腾讯云 (tencent.com)

springgateway动态路由的四类实现方式_BUG弄潮儿的博客-CSDN博客

（Spring Cloud Gateway本身还不支持直接从Nacos动态加载路由配置表，需要自己编写监听器监听配置变化并刷新路由表。）

Spring Cloud Gateway 多种思路实现动态路由 - 简书 (jianshu.com)

15、SpringCloud 限流

SpringCloud Gateway 使用 Sentinel 实现服务限流熔断_大雪冬至的博客-CSDN博客_gateway sentinel熔断

Spring Cloud Gateway 限流实战，终于有人写清楚了！-阿里云开发者社区 (aliyun.com)

16、SpringCloud 整合gateway实现负载均衡：

Spring Cloud Gateway负载均衡 - 简书 (jianshu.com)

17、SpringCloud Slueth+Zipkin 链路追踪：

Spring Cloud 系列之 Sleuth 链路追踪（一） - 知乎 (zhihu.com)

18、Nacos 原理_Heloise_yangyuchang的博客-CSDN博客_nacos原理

19、基于Gateway实现网关鉴权&分发 - 知乎 (zhihu.com)

20、gateway集群搭建：

Spring Cloud GateWay网关集群搭建_Cinderella100100100的博客-CSDN博客_springcloudgateway集群部署

21、seata分布式事务

Transaction Coordinator (TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运
行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
Transaction Manager (TM)：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终
向TC发起全局提交或全局回滚的指令。
Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分
支（本地）事务的提交和回滚。

（二）分布式事务——Seata、XA、TCC、AT、SAGA模式_分布式_方方土^_^-DevPress官方社区 (csdn.net)

视频：分布式事务：Seata-AT模式_哔哩哔哩_bilibili

22、seata AT 模式：

Seata：Spring Cloud Alibaba分布式事务组件（非常详细） (biancheng.net)

23、seata TCC模式：

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂:
空回滚：
在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回
滚，然后直接返回成功。
出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶
段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回
滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分
布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会
插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存
在，则是空回滚。
幂等：
通过前面介绍已经了解到，为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、
Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据
不一致等严重问题。
解决思路在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。
悬挂：
悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。
出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，
通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求
才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预
留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。
解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支
事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

Seata TCC模式实战_斗者_2013的博客-CSDN博客_seata tcc实战

24、seata的几种模式的对比较：

AT：
   ~ 基于sql层面，进行sql解析，并记录sql执行前后的数据，持久化到 undo.log（修改前数据）和redo.log（修改后数据）
   ~ AT模式的RM在本地事务执行完成后就会提交事务，不会占用本地资源
   ~ 最终一致性，可能会出现脏读
   ~ 业务无侵入
XA：
   ~ 基于XA协议，全局一致性，没有数据日志的记录，由 XA 分支来执行 sql 进入准备状态，通知 TC ，由进行对各个（RM）分支事务处理
   ~ XA模式则是在所有的本地事务执行完成后，TC才发送指令让所有的RM提交事务、释放本地锁
   ~ 强一致性，因为都是它一直占着，不全部执行完就不放。因此XA模式是不会出现脏读
   ~ 业务无侵入
XA 和 AT 共同点：基于支持本地 ACID 事务的关系型数据库
TCC：
   ~ 不依赖于底层数据资源的事务支持
   ~ 侵入性较强，需自己编写事务控制逻辑
   ~ 全局基本没有锁，性能较强
   ~ 业务侵入
Sage：
   ~ 基于事件来驱动的，各个参与者之间的是异步执行的，Saga模式是一种长事务解决方案
   ~ 业务侵入