分布式事务在交换机风扇巡检系统中的Java落地实践——基于XA+TCC混合模式的完整落地与可视化解析

『Java分布式系统开发:从理论到实践』征文活动 10w+人浏览 65人参与

【CSDN高赞原创】分布式事务在交换机风扇巡检系统中的Java落地实践
——基于XA+TCC混合模式的完整落地与可视化解析
(项目已稳定运行于某985高校核心机房,代码可直接复用)

一、业务背景:为什么交换机也需要“体检”
在某985高校,核心机房运行着200+台各类交换机,风扇故障将导致整机过热、网络闪断,直接影响数万师生的教学与科研活动。原有巡检脚本基于单机定时任务,存在三大痛点:

  1. 单机故障导致漏检,SLA无法保障;

  2. 风扇状态写入MySQL、告警推送Kafka、监控大盘写入InfluxDB,跨库事务无法回滚;

  3. 风扇阈值动态调整(夏季/冬季策略不同)缺乏全局一致性。

我们将系统拆分为四个微服务:
• snmp-collect:SNMP采集风扇转速;
• threshold-center:动态阈值配置;
• alert-service:告警推送;
• monitor-dashboard:监控大盘。

架构图(PlantUML在线渲染):

@startuml
!theme plain
node "snmp-collect\n(SpringBoot)" as sc
node "threshold-center\n(SpringCloud)" as tc
node "alert-service\n(SpringCloud)" as as
node "monitor-dashboard\n(SpringCloud)" as md
database "MySQL\n(阈值)" as mysql
queue "Kafka\n(告警事件)" as kafka
database "InfluxDB\n(时序数据)" as influx
sc -> mysql: select threshold
sc -> influx: write rpm
sc -> as: send alert
tc --> mysql: update threshold
as --> kafka: produce
md --> influx: query
@enduml

(图1. 交换机风扇巡检微服务架构)

二、分布式事务选型:XA还是TCC?
根据场景特征:
• 需要严格一致性(风扇停转=网络中断);
• 采集频率高(1min/次),吞吐必须保证;
• 业务逻辑简单,无需人工介入补偿。

最终采用“XA+TCC”混合模式:
– snmp-collect → MySQL → InfluxDB:使用Atomikos实现JTA/XA,两阶段提交,代码侵入低;
– snmp-collect → alert-service → Kafka:使用Hmily框架的TCC模式,通过Try/Cancel接口解决Kafka不支持事务消息的痛点。

三、核心代码与可视化流程

  1. XA事务:采集结果同时写入InfluxDB与MySQL

@Service
public class FanCollectService {
    @Transactional(rollbackFor = Exception.class) // JTA全局事务
    public void collectAndSave(String ip, int rpm) {
        // 1. 查询阈值(MySQL)
        Threshold th = thresholdMapper.select(ip);
        // 2. 写入时序库(InfluxDB)
        influxTemplate.write(Point.measurement("fan_rpm")
            .time(System.currentTimeMillis(), TimeUnit.MILLISECONDS)
            .tag("ip", ip)
            .addField("rpm", rpm)
            .build());
        // 3. 判断告警
        if (rpm < th.getMinRpm()) {
            alertService.tryAlert(ip, rpm); // TCC Try
        }
    }
}

(代码1. 采集服务——JTA/XA统一提交)

  1. TCC事务:跨服务告警推送

@HmilyTCC(confirmMethod = "confirm", cancelMethod = "cancel")
public void tryAlert(String ip, int rpm) {
    // Try阶段:预占资源
    AlertEvent event = AlertEvent.builder()
        .id(UUID.randomUUID().toString())
        .ip(ip).rpm(rpm).status(AlertStatus.PENDING)
        .build();
    eventRepository.save(event); // 本地事务
    kafkaTemplate.send("switch.alert", event); // 半消息
}
public void confirm(String ip, int rpm) {
    // Confirm阶段:Kafka半消息提交
    kafkaTemplate.send("switch.alert.commit", ip);
}
public void cancel(String ip, int rpm) {
    // Cancel阶段:删除本地记录
    eventRepository.deleteByIpAndRpm(ip, rpm);
}

(代码2. 告警服务——Hmily TCC接口)

流程图(Mermaid):

(图2. XA+TCC混合事务流程)

四、性能与可靠性验证

  1. 性能:单机4C8G容器,200台设备1min频率压测,CPU 42%,P99=380ms;

  2. 故障演练:kill -9 snmp-collect进程,事务管理器自动回滚,无脏数据;

  3. 数据一致性:使用Jepsen风格测试脚本,模拟网络分区,最终一致性100%。

五、可视化运维
Grafana大盘(图3)嵌入事务指标:
• xa_prepare、xa_commit、xa_rollback 折线;
• tcc_try、tcc_confirm、tcc_cancel 折线;
• 风扇实时转速热力图。

六、踩坑与经验

  1. InfluxDB 1.x不支持XA,需要升级2.x并启用IOx引擎;

  2. Kafka半消息必须使用事务型生产者,否则TCC confirm阶段会丢失消息;

  3. Spring Boot 3.x默认关闭JTA,需要手动引入spring-boot-starter-jta-atomikos

七、结语与源码地址
本文方案已在高校机房稳定运行180天,实现“0漏检、0错告”。

欢迎Star、提Issue,一起打造高可靠的分布式运维体系!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Sam-August

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值