本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：一套开箱即用的SpringBoot消息通信工程，内置ActiveMQ作为消息中间件，原生支持MQTT协议，专为物联网低带宽设备设计。项目结构规范，包含完整的生产者发送接口（REST Controller调用）、消费者监听器（MessageListener实现）、Topic主题订阅逻辑及业务消息处理器。pom.xml已集成spring-boot-starter-artemis、activemq-client和org.eclipse.paho:mqtt-client等核心依赖，避免版本冲突。Java源码按功能分层组织在src/main/java下，涵盖Config配置类（含MQTT连接工厂、Topic订阅配置）、Service业务处理、Listener消息监听、Controller对外接口。编译后字节码位于classes目录，target目录生成可直接java -jar启动的独立jar包。支持设备端通过MQTT发布状态数据到指定Topic，服务端实时订阅并响应指令；也支持服务端向设备Topic推送控制命令，实现远程指令下发与状态回传闭环。适用于智能硬件接入、边缘设备管理、远程监控等典型场景。

1. 项目概述：为什么这套通信工程能真正“开箱即用”

我做过不下二十个物联网后台通信模块，从早期用Netty手写TCP长连接，到后来上RabbitMQ集群、Kafka流处理，再到这两年集中打磨轻量级MQTT接入方案。说实话，很多所谓“SpringBoot + MQTT”的Demo工程，跑起来第一件事就是改配置——不是ActiveMQ端口被占，就是pom里依赖版本打架导致ClassNotFoundException；要么消费者监听器死活收不到消息，查半天发现是Topic通配符写成了#却没开启useJmx=false；更常见的是设备连上了但发不出数据，最后定位到Paho客户端默认QoS=0，而设备固件要求QoS=1才触发ACK……这些坑，每一个都够新手折腾一整天。

这套工程之所以敢叫“可运行”，是因为它从第一天就按真实产线节奏设计：不追求炫技的多协议混搭，只聚焦MQTT这一种最适配低功耗设备的协议；不堆砌Spring Cloud全家桶，用最精简的SpringBoot 2.7.x（兼容Java 8）打底；ActiveMQ选的是5.16.5稳定版，而非Artemis（虽然starter名字叫spring-boot-starter-artemis，但实际底层桥接的是Classic ActiveMQ，这点在Config类里有明确注释）；所有Topic命名采用device/{deviceId}/status和device/{deviceId}/command两级结构，既支持单设备精准通信，又可通过device/+/status做全局状态聚合——这不是拍脑袋定的，而是我们给三家智能电表厂商落地时反复验证过的路径。

关键词里的“SpringBoot, ActiveMQ, MQTT, 消息通信, Topic订阅”，每个词背后都对应着一个必须闭环的实操环节：SpringBoot负责快速启动与依赖注入，ActiveMQ提供可靠的消息存储与分发能力，MQTT解决设备侧资源受限问题，消息通信强调双向性（不只是服务端下发，更要设备主动上报），Topic订阅则决定了消息路由的灵活性与扩展性。它适合三类人：一是嵌入式工程师想快速验证设备固件的MQTT对接逻辑，直接拿jar包丢进树莓派跑；二是后端新人要理解IoT系统消息流转全链路，代码结构清晰到每个类职责单一；三是运维同事需要部署一套零配置依赖的轻量级中间件，连Dockerfile都给你写好了（在resources/docker下）。它不解决高并发百万连接，但能把1000台设备的状态采集+指令下发稳稳扛住——这才是工业现场真正需要的“够用”。

2. 整体架构设计与技术选型深挖

2.1 为什么放弃Kafka/RabbitMQ，坚持用ActiveMQ+MQTT组合

很多人看到“物联网”第一反应是Kafka，毕竟吞吐量高、分区容错强。但真正在边缘场景落地过就会明白：Kafka的ZooKeeper依赖、Broker集群配置复杂度、以及设备端SDK体积（Java客户端超3MB），对STM32F4这类只有1MB Flash的MCU来说是灾难。RabbitMQ虽轻量些，但AMQP协议栈在设备端实现成本高，且其默认的Exchange/Queue模型不如MQTT的Topic树直观——你要让硬件工程师理解“direct exchange绑定key”，远不如告诉他“往device/001/status发JSON就行”。

ActiveMQ Classic（非Artemis）在这里成了最优解：单机模式下内存占用<128MB，启动时间<3秒；原生支持MQTT 3.1.1协议（无需额外插件）；内置Web控制台（http://localhost:8161/admin）可实时查看Topic连接数、消息堆积量；最关键的是它的mqttTransport层对QoS 1/2的支持极其稳定——我们曾用同一套代码压测，当设备以100ms间隔持续发送QoS=1消息时，ActiveMQ的inflight队列始终维持在<5条，而某些MQTT Broker在相同压力下会因ACK超时导致消息重复堆积。

提示：pom.xml中spring-boot-starter-artemis看似矛盾，实则是Spring Boot 2.7.x的兼容性设计。该starter内部会自动降级使用activemq-client，并在application.yml中通过spring.artemis.mode=classic显式声明。这是为后续升级Artemis预留的钩子，当前工程完全基于Classic ActiveMQ运行。

2.2 MQTT协议层的关键取舍：QoS、Clean Session与Keep Alive

设备端通信不是写Web API，协议细节直接决定稳定性。本工程在MqttConfig.java中做了三项硬性约束：

  • QoS强制设为1：QoS=0无确认，网络抖动时消息丢失不可追溯；QoS=2虽可靠但握手开销大，对电池供电设备不友好。QoS=1在“至少一次送达”与“低开销”间取得平衡，配合ActiveMQ的持久化策略（<policyEntry queue=">" producerFlowControl="true" memoryLimit="1mb"/>），确保消息不丢不重。

  • Clean Session=true：设备重启后不继承旧会话，避免因上次未ACK的消息堆积导致新连接卡顿。这牺牲了“离线消息补推”能力，但换来确定性——每次连接都是干净状态，调试时不用猜“是不是历史消息在捣鬼”。

  • Keep Alive=60秒：这是经过实测的黄金值。太短（如15秒）会增加心跳包频次，加速设备耗电；太长（如120秒）则网络中断后服务端无法及时感知断连，导致指令下发延迟。我们在LoRaWAN网关环境下测试，60秒Keep Alive配合ActiveMQ的transportConnector中maxInactivityDuration=30000（5秒无心跳即断连），能保证设备掉线后3秒内触发ConnectionLostException回调，业务层可立即标记设备为离线。

2.3 工程分层逻辑：为什么Controller不直接调用MQTT Client

看源码你会发现：DeviceCommandController接收HTTP请求后，不是直接用MqttClient.publish()发消息，而是调用CommandService.sendCommand()；后者再委托MqttProducer完成实际发布。这种看似“绕路”的设计，源于两个血泪教训：

  1. 事务一致性：某次客户要求“下发指令后同步更新数据库设备状态”，若Controller直连MQTT Client，当publish()成功但DB写入失败时，指令已发出却状态未更新，形成数据不一致。现在通过Service层统一管理，可用@Transactional包裹DB操作与消息发送（虽MQTT本身不支持XA事务，但通过本地消息表+定时补偿机制可兜底）。

  2. 协议隔离：未来若需支持CoAP协议（如NB-IoT设备），只需新增CoapProducer实现同一接口，Controller和Controller完全不用改。我们已在Producer接口中定义send(String topic, byte[] payload, int qos)方法，所有协议实现都遵循此契约。

注意：MqttListener类实现MessageListener接口而非@EventListener，是因为后者依赖Spring事件机制，无法捕获MQTT协议层的原始字节流。而MessageListener直接接收ActiveMQTextMessage对象，可获取getJMSType()、getJMSReplyTo()等JMS标准属性，为后续做消息路由（如根据JMSReplyTo字段自动回发响应）留出空间。

3. 核心模块详解与实操要点

3.1 配置模块：application.yml与MqttConfig.java的协同逻辑

配置不是简单填参数，而是构建通信链路的基石。application.yml中关键配置如下：

mqtt:
  broker-url: tcp://localhost:61613
  client-id: springboot-server
  username: admin
  password: admin
  connection-timeout: 30000
  timeout: 30000
  topics:
    status: device/+/status
    command: device/+/command
    broadcast: system/broadcast

这里broker-url指向ActiveMQ的MQTT传输端口（61613），而非OpenWire端口（61616）——这是新手最容易踩的坑。topics.status用+通配符而非#，因为+只匹配单级路径（device/001/status、device/002/status），而#会匹配多级（device/001/sub/status），在设备数量少时没问题，但当设备数超万级，#会导致Topic树膨胀，影响ActiveMQ路由性能。

MqttConfig.java则负责将YAML配置转化为运行时对象：

@Bean
public MqttConnectOptions mqttConnectOptions() {
    MqttConnectOptions options = new MqttConnectOptions();
    options.setUserName(mqttProperties.getUsername());
    options.setPassword(mqttProperties.getPassword().toCharArray());
    options.setCleanSession(true); // 强制覆盖YAML，杜绝配置遗漏风险
    options.setKeepAliveInterval(60);
    options.setConnectionTimeout(mqttProperties.getConnectionTimeout());
    return options;
}

重点在于setCleanSession(true)这行——即使YAML里没配，代码层也强制设为true。这是防御性编程：避免因配置文件被误删某行导致设备连接异常。

3.2 生产者模块：如何安全地向设备Topic发指令

MqttProducer.java的核心方法sendCommand(String deviceId, String commandJson)实现如下：

public void sendCommand(String deviceId, String commandJson) {
    String topic = String.format("device/%s/command", deviceId);
    try {
        // 1. 先检查设备是否在线（通过ActiveMQ管理API）
        if (!isDeviceOnline(deviceId)) {
            log.warn("Device {} is offline, command will be discarded", deviceId);
            return;
        }
        // 2. 构建MQTT消息
        MqttMessage message = new MqttMessage(commandJson.getBytes(StandardCharsets.UTF_8));
        message.setQos(1);
        message.setRetained(false);
        // 3. 发布到Topic
        mqttClient.publish(topic, message);
        log.info("Command sent to device {}: {}", deviceId, commandJson);
    } catch (MqttException e) {
        log.error("Failed to send command to device {}", deviceId, e);
        // 触发告警：推送企业微信机器人
        alertService.sendAlert("MQTT指令发送失败", 
            String.format("设备%s, 错误码%d", deviceId, e.getReasonCode()));
    }
}

这里有两个关键点：
- 设备在线校验：调用ActiveMQ的/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/ConsumerCount接口，统计device/001/command Topic下的消费者数量。若为0，说明设备未连接或订阅失败。这比单纯发消息更可靠——避免指令石沉大海。
- 错误码分级处理：MqttException.getReasonCode()返回不同数值（如32103=连接超时，32104=认证失败），alertService根据码值决定告警级别。比如32104需立即通知运维重置密码，而32103可先重试3次再告警。

3.3 消费者模块：监听器如何应对消息乱序与重复

MqttListener.java实现MessageListener接口，核心逻辑在onMessage(Message message)：

@Override
public void onMessage(Message message) {
    try {
        if (!(message instanceof ActiveMQTextMessage)) {
            log.warn("Received non-text message, ignored");
            return;
        }
        ActiveMQTextMessage textMessage = (ActiveMQTextMessage) message;
        String topic = textMessage.getJMSDestination().toString(); // 获取真实Topic
        String payload = textMessage.getText();

        // 解析Topic提取deviceId：device/001/status -> 001
        String deviceId = extractDeviceId(topic);
        if (deviceId == null) {
            log.warn("Invalid topic format: {}", topic);
            return;
        }

        // 1. 去重：用Redis记录最近10分钟内的msgId（JMSMessageID）
        String msgId = textMessage.getJMSMessageID();
        if (redisTemplate.opsForValue().get("dedup:" + msgId) != null) {
            log.debug("Duplicate message ignored: {}", msgId);
            return;
        }
        redisTemplate.opsForValue().set("dedup:" + msgId, "1", Duration.ofMinutes(10));

        // 2. 业务处理
        deviceStatusService.handleStatusUpdate(deviceId, payload);

    } catch (Exception e) {
        log.error("Error processing MQTT message", e);
        // 消息入DLQ（Dead Letter Queue）
        moveToDlq(message);
    }
}

去重逻辑值得细说：MQTT QoS=1本身可能导致消息重复（网络抖动时Broker重发），而设备端也可能因ACK超时重复发送。我们用Redis缓存JMSMessageID（ActiveMQ自动生成的唯一ID），有效期10分钟——这个值来自实测：设备固件重发间隔通常为5~8秒，10分钟足够覆盖所有重发窗口，又不会让Redis内存暴涨。

实操心得：moveToDlq()方法不是简单丢弃消息，而是将原消息包装成ActiveMQMapMessage，添加originalTopic、processTime、errorStack等字段后发往ActiveMQ.DLQ队列。运维可通过Web控制台手动查看DLQ内容，定位是设备固件bug还是服务端解析异常。

3.4 Topic订阅机制：动态订阅与静态订阅的混合策略

工程支持两种订阅模式：
- 静态订阅：在MqttConfig.java中通过@PostConstruct方法，在服务启动时订阅device/+/status等通配符Topic。适用于全局监控场景，如运维大屏实时显示所有设备在线率。
- 动态订阅：DeviceSubscribeService.java提供subscribeToDevice(String deviceId)方法，运行时为特定设备创建专属消费者。例如当用户在Web端点击“查看设备001实时日志”，后端调用此方法订阅device/001/log，日志流通过SSE推送到前端，关闭页面时自动取消订阅。

动态订阅的关键在于MqttClient的subscribe()方法支持多Topic数组，且可随时调用unsubscribe()。我们封装了SubscriptionManager类，用ConcurrentHashMap<String, List<String>>维护deviceId -> [topic1, topic2]映射，确保同一设备多次订阅不重复，取消订阅时精准移除。

4. 完整实操流程与关键步骤拆解

4.1 环境准备：三步启动ActiveMQ并验证MQTT端口

别急着跑SpringBoot，先确保消息中间件就绪。ActiveMQ 5.16.5安装极简：

# 下载并解压（Linux/macOS）
wget https://archive.apache.org/dist/activemq/5.16.5/apache-activemq-5.16.5-bin.tar.gz
tar -xzf apache-activemq-5.16.5-bin.tar.gz
cd apache-activemq-5.16.5

# 启动（后台运行）
bin/activemq start

# 验证MQTT端口（61613）是否监听
netstat -tuln | grep 61613
# 应输出：tcp6 0 0 :::61613 :::* LISTEN

# 访问Web控制台（默认admin/admin）
open http://localhost:8161/admin

注意：Windows用户请用bin\activemq.bat start，若提示“找不到Java”，需在bin\env中设置JAVA_HOME。我们实测过，ActiveMQ 5.16.5在JDK 8u291及以上版本运行最稳，低于此版本可能出现SSL握手失败。

4.2 工程编译与启动：从源码到可执行jar的全流程

假设你已克隆仓库，目录结构如下：

springboot-mqtt-demo/
├── pom.xml
├── src/
│   └── main/
│       ├── java/com/example/mqtt/
│       └── resources/application.yml
└── target/

执行以下命令：

# 1. 清理并编译（跳过测试，加快速度）
mvn clean compile -Dmaven.test.skip=true

# 2. 打包成可执行jar（含所有依赖）
mvn package -Dmaven.test.skip=true

# 3. 启动服务（默认端口8080，ActiveMQ地址localhost:61613）
java -jar target/springboot-mqtt-demo-1.0.0.jar

# 4. 验证服务健康（返回{"status":"UP"}）
curl http://localhost:8080/actuator/health

此时控制台应输出：

INFO  o.a.a.b.BrokerService - Apache ActiveMQ 5.16.5 starting
INFO  c.e.m.c.MqttConfig - MQTT client connected to tcp://localhost:61613
INFO  c.e.m.l.MqttListener - Subscribed to topic: device/+/status
INFO  c.e.m.l.MqttListener - Subscribed to topic: device/+/command

4.3 设备端模拟：用Paho Python脚本验证双向通信

没有真实设备？用Python脚本模拟最直观。安装paho-mqtt：

pip install paho-mqtt

设备上报脚本（device_simulator.py）：

import paho.mqtt.client as mqtt
import json
import time

def on_connect(client, userdata, flags, rc):
    print(f"Connected with result code {rc}")
    # 连接后立即订阅command Topic
    client.subscribe("device/001/command")

def on_message(client, userdata, msg):
    print(f"Received command: {msg.payload.decode()}")
    # 模拟执行指令后回传状态
    status = {"deviceId": "001", "status": "executed", "timestamp": int(time.time())}
    client.publish("device/001/status", json.dumps(status))

client = mqtt.Client("device-001")
client.username_pw_set("admin", "admin")
client.on_connect = on_connect
client.on_message = on_message

client.connect("localhost", 61613, 60)
client.loop_start()

# 每5秒上报一次状态
while True:
    status = {"deviceId": "001", "battery": 85, "temperature": 23.5, "timestamp": int(time.time())}
    client.publish("device/001/status", json.dumps(status))
    time.sleep(5)

服务端指令下发（test_command.py）：

import paho.mqtt.client as mqtt
import json

client = mqtt.Client("server-test")
client.username_pw_set("admin", "admin")
client.connect("localhost", 61613, 60)

# 向设备001下发重启指令
command = {"action": "reboot", "delay": 0}
client.publish("device/001/command", json.dumps(command))
print("Reboot command sent to device 001")

运行device_simulator.py后，观察SpringBoot日志：

INFO  c.e.m.l.MqttListener - Received status from device 001: {"deviceId":"001","battery":85,...}
INFO  c.e.m.s.DeviceStatusService - Device 001 status updated: battery=85, temp=23.5

再运行test_command.py，设备端控制台会打印：

Received command: {"action": "reboot", "delay": 0}

双向闭环验证完成。

4.4 REST接口调用：通过HTTP下发指令的完整链路

工程提供/api/v1/device/{deviceId}/command接口，用curl测试：

# 发送重启指令
curl -X POST http://localhost:8080/api/v1/device/001/command \
  -H "Content-Type: application/json" \
  -d '{"action":"reboot","delay":30}'

# 返回：{"code":200,"message":"Command sent successfully"}

跟踪代码链路：
1. DeviceCommandController.command()接收请求 →
2. 调用CommandService.sendCommand() →
3. MqttProducer.sendCommand()构建MQTT消息 →
4. ActiveMQ将消息路由至device/001/command →
5. 设备端（或模拟脚本）收到并执行 →
6. 设备回传状态到device/001/status →
7. MqttListener捕获并调用deviceStatusService.handleStatusUpdate() →
8. 状态存入数据库（H2内存库，生产环境替换为MySQL）

整个链路耗时通常<200ms（局域网环境），瓶颈在设备端处理，而非服务端。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

问题现象 可能原因 排查命令/步骤 解决方案
服务启动报错：Failed to connect to broker ActiveMQ未启动或端口被占 netstat -tuln \| grep 61613 启动ActiveMQ或修改application.yml中mqtt.broker-url
设备能连MQTT但收不到指令 Topic订阅错误（如device/001/command vs device/001/cmd） Web控制台→Queues→查看device.001.command队列是否有消息 检查设备端订阅Topic与服务端发布Topic是否完全一致
服务端收不到设备状态 设备QoS=0且网络不稳定 tcpdump -i lo port 61613 -w mqtt.pcap抓包分析 设备端强制设QoS=1，服务端MqttConnectOptions中setCleanSession(true)
日志疯狂打印Duplicate message ignored Redis去重Key过期时间太短 redis-cli TTL dedup:ID123 将Duration.ofMinutes(10)改为Duration.ofMinutes(30)
Web控制台看不到MQTT连接 ActiveMQ未启用MQTT传输器 检查conf/activemq.xml中<transportConnectors>是否含<transportConnector name="mqtt" uri="mqtt://0.0.0.0:61613"/> 取消该行注释并重启ActiveMQ

5.2 深度排查技巧：用JMX定位消息堆积

当设备大量上线，发现device/+/status Topic消息堆积，Web控制台只显示总数，无法定位具体设备。此时用JMX：

# 进入ActiveMQ安装目录
cd apache-activemq-5.16.5

# 启动JConsole（需JDK自带）
jconsole

# 连接进程：选择`org.apache.activemq.console.Main`，点“连接”
# 在MBeans选项卡中展开：
#   org.apache.activemq → Broker → localhost → Topic → device.001.status
# 查看Attributes中的`QueueSize`、`ConsumerCount`

若QueueSize持续增长而ConsumerCount=0，说明设备未正确订阅；若ConsumerCount>0但QueueSize仍涨，则可能是MqttListener处理慢（如DB写入阻塞），需检查deviceStatusService方法执行时间。

5.3 生产环境加固清单

这套工程开箱即用，但上线前必须做五件事：

  1. 密码强制修改：application.yml中mqtt.username/password和ActiveMQ的conf/users.properties必须改掉默认admin/admin，否则等于裸奔。

  2. Topic权限控制：在conf/activemq.xml中添加<authorizationPlugin>，限制设备只能发布device/*/status，只能订阅device/*/command，禁止访问system/*等敏感Topic。

  3. 消息持久化开关：application.yml中添加mqtt.persistent=true，MqttProducer中message.setRetained(true)，确保设备离线期间指令不丢失（需配合cleanSession=false）。

  4. 日志分级：将MqttListener的日志级别设为DEBUG，其他模块用INFO，避免海量MQTT日志冲垮磁盘。在logback-spring.xml中配置：
    xml <logger name="com.example.mqtt.listener" level="DEBUG"/>

  5. 健康检查增强：在application.yml中添加：
    yaml management: endpoint: health: show-details: when_authorized endpoints: web: exposure: include: health,metrics,prometheus
    这样Prometheus可拉取/actuator/prometheus指标，监控mqtt_client_connected、mqtt_messages_received_total等关键数据。

我个人在实际部署中发现：只要把conf/activemq.xml中的<systemUsage>内存限制从默认64mb调到256mb，再配合<policyEntry queue=">" memoryLimit="1mb"/>，这套组合就能稳稳支撑5000+设备。超过这个量级，建议按区域拆分ActiveMQ集群，而非强行堆配置。

6. 扩展可能性与演进路径

这套工程不是终点，而是IoT通信架构的起点。根据我们给客户落地的经验，后续可自然延伸三条路径：

  • 协议扩展：在Producer和Consumer接口基础上，新增CoapProducer和CoapConsumer，复用现有Service层。CoAP的CON（Confirmable）消息天然对应MQTT QoS=1，只需将CoapClient的Request对象映射为MqttMessage，业务逻辑零改造。

  • 规则引擎集成：引入Drools，在deviceStatusService.handleStatusUpdate()中插入规则判断。例如当temperature > 80且battery < 20时，自动触发sendCommand(deviceId, {"action":"shutdown"})。规则文件放在resources/rules/下，热加载无需重启。

  • 时序数据沉淀：将设备状态JSON解析后，写入InfluxDB而非关系库。修改DeviceStatusService，用InfluxDBClient的WriteApi批量写入，Tag设为deviceId，Field为battery、temperature，时间戳用消息中的timestamp。这样Grafana可直接对接，做设备健康度大盘。

最后分享一个小技巧：如果客户要求“设备上线后自动推送固件升级包”，不要在onMessage()里直接下载大文件。而是用MqttProducer发一条轻量指令{"action":"upgrade","url":"https://cdn.example.com/firmware_v2.1.bin"}，设备端自己下载校验。这样服务端内存不爆，网络带宽不占，升级过程完全由设备自主控制——这才是物联网该有的样子。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：一套开箱即用的SpringBoot消息通信工程，内置ActiveMQ作为消息中间件，原生支持MQTT协议，专为物联网低带宽设备设计。项目结构规范，包含完整的生产者发送接口（REST Controller调用）、消费者监听器（MessageListener实现）、Topic主题订阅逻辑及业务消息处理器。pom.xml已集成spring-boot-starter-artemis、activemq-client和org.eclipse.paho:mqtt-client等核心依赖，避免版本冲突。Java源码按功能分层组织在src/main/java下，涵盖Config配置类（含MQTT连接工厂、Topic订阅配置）、Service业务处理、Listener消息监听、Controller对外接口。编译后字节码位于classes目录，target目录生成可直接java -jar启动的独立jar包。支持设备端通过MQTT发布状态数据到指定Topic，服务端实时订阅并响应指令；也支持服务端向设备Topic推送控制命令，实现远程指令下发与状态回传闭环。适用于智能硬件接入、边缘设备管理、远程监控等典型场景。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
亚马逊云科技技术品牌专区

更多推荐

主动推理-人工海马

2026年07月04日 00:21发言人00:00制造能够思考的机器是人类长久以来的梦想，但这到底意味着什么呢？智能的一个显著特性是能够泛化知识，并灵活地将其应用于新情况。这种泛化确实是现代机器学习的核心问题之一。在这段视频中，我们将探讨如何汲取海马体负责记忆和导航的大脑结构的生物学组织，来构建一个能够学习构建抽象和泛化的计算模型。我们将探索这个模型带给我们关于大脑自身及人工智能领域的启示。发言人

avatar 亚马逊云科技技术品牌专区

分布式事务尝试取消确认模式的具体实现步骤

首先需要事务协调器（Transaction Coordinator），负责协调整个分布式事务的流程，记录事务状态，并在必要时触发补偿操作。尝试取消确认模式（Try-Cancel-Confirm，简称TCC）作为一种补偿型分布式事务解决方案，通过业务逻辑层面的拆解，提供了更灵活的一致性实现方式。未来，随着事务中间件的成熟和云原生技术的发展，TCC模式的实施成本将进一步降低，应用场景也将更加广泛。Co

avatar 亚马逊云科技技术品牌专区

Cursor + GitOps：自动化运维新姿势

Cursor 与 GitOps 的结合，标志着运维自动化从“脚本化”向“智能化”演进的关键一步。它并非要取代工程师，而是将其从重复劳动中解放出来，更专注于架构设计、复杂问题解决和流程优化。拥抱这一新姿势，意味着以更优雅、高效的方式驾驭云原生时代的运维复杂性。

avatar 亚马逊云科技技术品牌专区