-
nacos(服务发现和配置中心、元数据中心)
-
spring-cloud-loadbalancer(负载均衡)
-
Dubbo: RPC通信 与 微服务治理
-
sentinel 服务容错(流控、降级、服务负载)
-
spring-cloud-stream(mq封装)
-
SpringCloud Gateway (服务网关)
-
认证中心
-
Skywalking (链路追踪)
-
seata(分布式事务)
核心原理:Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务,而一个分支事务是一个满足 ACID 的本地事务,因此我们可以操作分布式事务像操作本地事务一样。
Seata 内部定义了 3个模块来处理全局事务和分支事务的关系和处理过程,这三个组件分别是:
- Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
- Transaction Manager (TM): 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
- Resource Manager (RM): 控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。
简要说说整个全局事务的执行步骤:
- TM 向 TC 申请开启一个全局事务,TC 创建全局事务后返回全局唯一的 XID,XID 会在全局事务的上下文中传播;
- RM 向 TC 注册分支事务,该分支事务归属于拥有相同 XID 的全局事务;
- TM 向 TC 发起全局提交或回滚;
- TC 调度 XID 下的分支事务完成提交或者回滚。
分支事务如何提交和回滚?
下面详细说说分支事务是如何提交和回滚的:
- 第一阶段:
分支事务利用 RM 模块中对 JDBC 数据源代理,加入了若干流程,对业务 SQL 进行解释,把业务数据在更新前后的数据镜像组织成回滚日志,并生成 undo log 日志,对全局事务锁的检查以及分支事务的注册等,利用本地事务 ACID 特性,将业务 SQL 和 undo log 写入同一个事物中一同提交到数据库中,保证业务 SQL 必定存在相应的回滚日志,最后对分支事务状态向 TC 进行上报。
- 第二阶段:
TM决议全局提交:
当 TM 决议提交时,就不需要同步协调处理了,TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可,这个步骤非常快速地可以完成。这个机制对于性能提升非常关键,我们知道正常的业务运行过程中,事务执行的成功率是非常高的,因此可以直接在本地事务中提交,这步对于提升性能非常显著。
TM决议全局回滚:
当 TM 决议回滚时,RM 收到 TC 发送的回滚请求,RM 通过 XID 找到对应的 undo log 回滚日志,然后利用本地事务 ACID 特性,执行回滚日志完成回滚操作并删除 undo log 日志,最后向 TC 进行回滚结果上报。
业务对以上所有的流程都无感知,业务完全不关心全局事务的具体提交和回滚,而且最重要的一点是 Seata 将两段式提交的同步协调分解到各个分支事务中了,分支事务与普通的本地事务无任何差异,这意味着我们使用 Seata 后,分布式事务就像使用本地事务一样,完全将数据库层的事务协调机制交给了中间件层 Seata 去做了,这样虽然事务协调搬到应用层了,但是依然可以做到对业务的零侵入,从而剥离了分布式事务方案对数据库在协议支持上的要求,且 Seata 在分支事务完成之后直接释放资源,极大减少了分支事务对资源的锁定时间,完美避免了 XA 协议需要同步协调导致资源锁定时间过长的问题。
Q:
Seata
作为分布式事务时,有些时候我们的分布式时候并不是每次都可以成功的,而对于这些失败的分布式事务就需要进行通知A:实现FailureHandler,来监听失败处理
-
elk
-
Prometheus/grafana(服务监控)(补充、可不看)
- Java89
- 数据库87
- JVM36
- 架构35
- Redis29
- MQ29
- Mysql27
- Java基础26
- 并发22
- RabbitMQ21
- ElasticSearch18
- Minio16
- IO14
- MyBatis14
- mongodb10
- 定时任务10
- 操作系统8
- 计算机网络6
- kafka6
- Blog5
- 使用指南5
- es5
- Java Web5
- CAS5
- Linux3
- 后台管理3
- 微服务3
- 收藏2
- OOM2
- 项目管理2
- 数据结构2
- Nginx2
- About1
- CRM1
- mall1
- 计算机组成原理1
- 技术管理1
- 技术选型1
- MySql1
- deploy1
- kenkins1
- Vue1
- 前端1
- Spring1
- 分库分表1
...大约 5 分钟
- 前端通过api 请求 到服务端经过F5硬件负载均衡和nginx 软件负载均衡、走到我们服务网关集群
- 网关针对请求做路由转发到各个的服务集群、各服务之间通过dubbo进行通信
- 其中各服务通过nacos 做服务注册中心与配置中心、sentinel 做流控降级
- 底层采用redis、mysql、minio、es 、rabbitmq 做数据支持
- 通过skywalking 和 springboot admin、elk 做系统监控
...小于 1 分钟
1. 微服务
1.1 为什么使用微服务
- 大型服务
- 单例服务如果流量大了就抗不住,微服务可以加机器搞流量
- 加机器的地方,最理想的就是:弹性伸缩,流量下去就缩容,流量上来就扩容,能最恰好的使用资源
- 传统的巨大单体应用程序在部署和运行时,需要单台服务器具有大量内存和其他资源
- 规范化
- 规范化,大家用同一套框架规范,可以沉淀和深入技术,还可以培养技术氛围
- 业务拆分
- 业务拆分,解耦业务,各司其职
...小于 1 分钟