PRC框架(以Dubbo为例),分布式事务解决方案
一、RPC框架:以Dubbo为例
1. Dubbo核心概念
Dubbo是阿里巴巴开源的一款高性能Java RPC框架,主要包含以下核心组件:
-
Provider:服务提供方,暴露服务
-
Consumer:服务消费方,调用远程服务
-
Registry:注册中心,负责服务注册与发现
-
Monitor:监控中心,统计服务调用次数和调用时间
-
Container:服务运行容器
2. Dubbo工作原理
-
服务暴露:Provider启动时向Registry注册自己提供的服务
-
服务订阅:Consumer启动时向Registry订阅所需服务
-
服务调用:Consumer通过获取的Provider地址列表,直接调用Provider
-
监控统计:Consumer和Provider定时发送统计数据到Monitor
3. Dubbo核心特性
-
负载均衡:支持Random、RoundRobin、LeastActive等多种策略
-
集群容错:提供Failover、Failfast、Failsafe等容错机制
-
服务治理:支持服务降级、动态配置、服务分组等
-
协议支持:默认使用Dubbo协议,也支持HTTP、RMI等
-
序列化:支持Hessian、JSON、Java原生序列化等
4. Dubbo示例代码
// 服务接口
public interface GreetingService {
String sayHello(String name);
}
// 服务实现
@Service
public class GreetingServiceImpl implements GreetingService {
@Override
public String sayHello(String name) {
return "Hello, " + name;
}
}
// 服务配置
@Configuration
@EnableDubbo(scanBasePackages = "com.example")
public class ProviderConfiguration {
@Bean
public RegistryConfig registryConfig() {
RegistryConfig registryConfig = new RegistryConfig();
registryConfig.setAddress("zookeeper://127.0.0.1:2181");
return registryConfig;
}
}
二、分布式事务解决方案
1. 分布式事务挑战
在微服务架构中,业务操作通常需要跨多个服务,传统单机事务无法满足需求,主要面临以下问题:
-
网络不可靠:服务间调用可能失败
-
性能问题:长事务会占用系统资源
-
数据一致性:如何保证多个服务数据最终一致
2. 常见解决方案
(1) Seata方案
Seata(Simple Extensible Autonomous Transaction Architecture)是阿里开源的分布式事务解决方案,支持AT、TCC、SAGA和XA模式。
AT模式(Auto Transaction)
工作原理:
-
一阶段:
-
解析SQL,生成前置镜像(before image)和后置镜像(after image)
-
执行业务SQL
-
提交前,向TC(Transaction Coordinator)注册分支事务
-
报告分支状态
-
-
二阶段:
-
成功:异步删除快照数据
-
失败:根据快照数据回滚
-
特点:
-
对业务无侵入
-
性能较好
-
依赖数据库快照能力
Seata架构组件
-
TC(Transaction Coordinator):事务协调器,维护全局事务状态
-
TM(Transaction Manager):事务管理器,定义全局事务边界
-
RM(Resource Manager):资源管理器,管理分支事务
(2) TCC模式(Try-Confirm-Cancel)
TCC是一种补偿型事务方案,将事务分为三个阶段:
-
Try:预留业务资源
-
Confirm:确认执行业务操作
-
Cancel:取消执行业务操作
示例流程:
订单服务 - 库存服务 - 账户服务
Try: 创建订单(状态:处理中) → 冻结库存 → 冻结金额
Confirm: 订单状态→成功 → 扣减库存 → 扣减金额
Cancel: 订单状态→失败 → 释放库存 → 释放金额
特点:
-
需要业务实现三个接口
-
性能较好
-
数据最终一致