RocketMQ 从入门到精通：Java 生态消息中间件实战详解

Ne0inhk

— 22 min read

RocketMQ 从入门到精通：Java 生态消息中间件实战详解

你想了解的是RocketMQ（并非 rollectMQ，为拼写误差），它是阿里开源的分布式消息中间件，基于 Java 开发，主打高吞吐、高可用、低延迟、分布式架构，脱胎于阿里内部的 MetaQ，后捐赠给 Apache 基金会成为顶级项目，广泛用于电商、金融、物流等领域的异步通信、流量削峰、分布式事务等场景，是 Java 生态中主流的消息队列之一。

一、RocketMQ 核心架构（4 大核心角色）

RocketMQ 采用分布式集群架构，核心由 4 个相互协作的角色组成，职责清晰、解耦性强，支撑海量消息的生产与消费，架构图核心逻辑如下：

生产者(Producer) → 姓名服务器(NameServer) → 代理服务器(Broker) ← 消费者(Consumer) ↑ ↑ | | 路由信息注册/发现 消息存储/转发

Master/Slave数据同步

1. 拉取Broker路由信息2. 发送消息（普通/顺序/事务等）

启动时注册/定时心跳

1. 拉取Broker路由信息2. 拉取消息并消费

消费者 Consumer

核心能力：
1. 集群/广播消费
2. 拉取模式负载均衡
3. 消费重试/死信处理

代理服务器 Broker

核心能力：
1. 消息存储/持久化
2. Master/Slave高可用
3. 消息转发/副本同步

姓名服务器 NameServer

核心能力：
1. 轻量级路由中心
2. Broker注册/发现
3. 无状态可集群

生产者 Producer

核心能力：
1. 集群部署
2. 三种发送模式
3. 动态获取路由

各角色核心职责：

1. NameServer（姓名服务器）

轻量级的路由注册中心，无状态、可集群部署（节点间不通信，靠生产者 / 消费者主动拉取）；

管理 Broker 节点的注册与发现：Broker 启动后向所有 NameServer 注册自身信息（地址、存储的 Topic 等），生产者 / 消费者通过 NameServer 获取最新的 Broker 路由信息，实现动态扩容；

核心作用：解耦生产者 / 消费者与 Broker，避免硬编码 Broker 地址，提升集群灵活性。

2. Broker（代理服务器）

RocketMQ 的核心节点，负责消息的存储、转发、持久化、高可用，是消息的实际载体；

可分为 Master 节点（主节点，处理生产 / 消费请求、存储消息）和 Slave 节点（从节点，同步 Master 数据，做容灾备份，默认不处理写请求，可配置为读从节点）；

支持多副本、多机房部署，通过同步 / 异步复制保证数据可靠性，是集群高可用的关键。

3. Producer（生产者）

消息的发送方，基于 Java 等语言开发（原生支持 Java，提供多语言 SDK）；

支持集群部署，通过 NameServer 获取 Broker 路由信息后，直接向 Broker 发送消息；

提供多种发送模式：同步发送（重要消息，如订单创建）、异步发送（高吞吐场景，如日志采集）、单向发送（无需回执，如心跳包）。

4. Consumer（消费者）

消息的接收方，同样支持集群部署；

通过 NameServer 获取 Broker 路由信息，从 Broker 拉取或推送消息（RocketMQ 主流为拉取模式，可根据消费能力动态调整拉取频率，避免消息堆积）；

核心消费模式：集群消费（同一条消息仅被消费集群中一个节点处理，适合负载均衡）、广播消费（同一条消息被所有消费节点处理，适合配置同步）。

补：简单举个例子便于理解与记忆（场景：“大型电商仓储物流中心” ）

NameServer → 物流调度中心

职能：掌握所有仓库（Broker）的地址、库存品类（Topic）等信息，是生产者和消费者的 “导航系统”。

举例：就像电商平台的调度中心，不存储商品，只记录每个仓库的位置和能发哪些品类的货。

协作逻辑：

  • 仓库（Broker）开业时，会主动向调度中心（NameServer）登记自己的地址和可发货品类。
  • 商家（Producer）要发货、买家（Consumer）要收货时，都先问调度中心 “哪个仓库有我要的货？地址在哪？”，再直接联系仓库。

Broker → 仓储配送中心

职能：消息的实际存储、转发和交付节点，是整个架构的核心载体。

举例：就像大型仓储配送中心，分为主仓（Master）和备用仓（Slave）。

协作逻辑：

  • 主仓负责接收商家送来的商品（消息），并同步给备用仓做备份，保证商品不会丢失。
  • 买家下单后，直接从主仓取货（拉取消息），如果主仓故障，备用仓可以立刻顶上。

Producer → 商家供应商

职能：产生消息并发送到 Broker，是消息的源头。

举例：就像给电商平台供货的商家，有货要卖时，先问调度中心（NameServer）哪个仓库能收这个品类的货，然后直接把商品送到指定仓库（Broker）。

协作逻辑：

  • 商家可以选择 “当面交货等签收”（同步发送，重要订单）、“送货后发通知不用等回复”（异步发送，高吞吐场景），或 “放下就走”（单向发送，日志上报）。

Consumer → 买家用户

职能：从 Broker 拉取消息并消费，是消息的最终使用者。

举例：就像在电商平台下单的买家，先问调度中心（NameServer）哪个仓库有自己要的商品，然后直接去仓库取货。

协作逻辑：

  • 如果是多人拼单（集群消费），同一件商品只会被一个买家拿走，避免重复；
  • 如果是 “商品上新通知”（广播消费），所有订阅了的买家都会收到消息。
  • 买家拿到货后如果发现有问题（消费失败），可以要求仓库重新发货（重试机制），实在解决不了的商品会被放到 “问题商品区”（死信队列）。

二、功能逻辑：三层核心架构（功能分层解耦）

从功能逻辑上，RocketMQ 将整体架构分为三层，每层职责明确，上层依赖下层，实现业务与底层、功能与存储的解耦，提升架构的扩展性和可维护性：

1. 接入层（Access Layer）

核心组件：Producer 生产者、Consumer 消费者；

核心职责：面向业务系统的消息接入与消费输出，屏蔽底层 RocketMQ 的路由细节和存储细节；

层能力：提供统一的消息发送 / 消费 API，支持多种消息类型（普通、顺序、延时、事务），处理业务侧的消息过滤、负载均衡。

2. 核心层（Core Layer）

核心组件：NameServer 路由中心、Broker 核心节点；

核心职责：RocketMQ 的核心处理层，负责路由管理、消息转发、高可用保障；

层能力：

  • NameServer 实现分布式服务发现，解耦接入层与存储层；
  • Broker 承接接入层的消息请求，完成消息的转发和高可用处理（主从同步），是三层架构的枢纽。

3. 存储层（Storage Layer）

核心载体：Broker 内置的消息存储模块（基于磁盘文件存储）；

核心职责：负责消息的持久化存储和快速读取，是 RocketMQ 数据可靠性的基础；

层能力：支持同步刷盘、异步刷盘两种持久化策略，基于高效的文件存储结构，实现海量消息的低延迟写入和读取，同时支持消息的过期删除、磁盘空间管理。

三、执行流程

执行链路：

生产者先找路由中心查仓库地址→发消息到指定仓库→仓库持久化 + 主从备份→消费者找路由中心查仓库地址→从仓库拉取消息并消费→反馈消费结果，全程解耦生产者 / 消费者与仓库，无单点依赖。

详细介绍：

按 “启动准备→消息生产→消息存储→消息消费→异常处理”5 个核心阶段拆解，每个阶段明确角色动作和协作逻辑：

阶段 1：集群启动 & 路由注册（所有角色初始化，做好准备）
  1. NameServer 先启动：所有 NameServer 节点启动后进入空闲状态，等待 Broker 注册路由信息（类似「物流调度中心先开业，等待各个仓库报备信息」）；
  2. Broker 启动并注册路由：Broker 主节点（Master）+ 从节点（Slave）启动后，向所有 NameServer 发送注册请求，包含自身 IP 地址、负责的 Topic 主题、主从节点映射关系等；NameServer 接收后更新本地路由表，Broker 后续会定时（默认 30 秒）发送心跳包，保证路由信息新鲜（类似「仓储中心开业后，向所有调度中心报备地址和可存货物品类，后续定时报活证明自己正常」）；
  3. Producer/Consumer 启动并初始化：生产者和消费者启动后，加载配置的 NameServer 地址，完成自身客户端初始化，等待业务触发消息发送 / 消费（类似「商家和买家准备好，随时可以发货 / 下单」）。
阶段 2：消息生产流程（Producer → NameServer → Broker）

核心：生产者不直接连 Broker，先寻址再发送，支持 3 种发送模式

  1. 拉取路由信息：Producer 接收到业务发送消息的请求后，首先向任意一个 NameServer 发送请求，拉取目标 Topic 对应的 Broker 地址列表（优先主节点）（类似「商家要发货，先问调度中心‘哪个仓库能存这个品类的货，地址是啥’」）；
  2. 选择发送节点：Producer 根据内置负载均衡策略（如轮询、随机），从 Broker 地址列表中选择一个主节点作为发送目标；
  3. 发送消息：Producer 向选定的 Broker 主节点发送消息，支持 3 种模式（适配不同业务）：
    • 同步发送：等待 Broker 回执（成功 / 失败），适合重要消息（如订单创建）；
    • 异步发送：发送后无需等待，Broker 处理完成后回调通知，适合高吞吐场景（如日志采集）；
    • 单向发送：只发不等待回执，适合非核心消息（如心跳包）；
  4. 生产结果回执：Broker 主节点接收到消息后，立即向 Producer 返回「消息接收成功」回执（此时消息尚未持久化，可配置同步刷盘保证强一致性）。
阶段 3：消息存储 & 高可用（Broker 内部核心操作）

核心：Broker 是消息实际载体，完成持久化 + 主从同步，保证数据不丢

  1. 写入 CommitLog：Broker 主节点将接收到的消息，按写入顺序统一写入全局日志文件 CommitLog（磁盘顺序写，保证高吞吐），这是 RocketMQ 消息存储的核心（类似「仓库主仓把商家送来的商品，按到货顺序统一放入总货架」）；
  2. 构建 ConsumeQueue 索引：Broker 从 CommitLog 中解析消息的 Topic、Queue 等信息，为每个 Topic 构建专属索引文件 ConsumeQueue（仅存储消息在 CommitLog 中的偏移量、大小等轻量信息），方便后续消费者快速查找（类似「仓库为每个品类的商品，建立专属货架索引，标注‘总货架第 X 层’，不用全局翻找」）；
  3. 主从同步备份：Broker 主节点将新写入的消息，通过同步 / 异步复制策略同步给对应的 Slave 从节点；从节点接收到消息后，执行和主节点相同的存储操作（写入 CommitLog + 构建 ConsumeQueue），完成数据备份（类似「主仓每收到一批商品，立即同步给备用仓，备用仓按相同规则存放，保证主仓出问题时备用仓能直接顶上」）；
  4. 消息持久化刷盘：Broker 根据配置（同步刷盘 / 异步刷盘），将内存中的消息刷入磁盘，完成最终持久化：
    • 同步刷盘：写入内存后立即刷盘，刷盘成功后再反馈，强一致性但性能稍低；
    • 异步刷盘：写入内存后先反馈，后台线程定时刷盘，性能高但存在极短时间的内存丢失风险（适合大部分企业场景）。
阶段 4：消息消费流程（Consumer → NameServer → Broker）

核心：消费者采用「拉取模式」（Pull），按需拉取消息，支持集群 / 广播消费

  1. 拉取路由信息：Consumer 启动后（或首次消费目标 Topic 时），向任意一个 NameServer 发送请求，拉取目标 Topic 对应的 Broker 地址列表（类似「买家要下单，先问调度中心‘哪个仓库有这个商品，地址是啥’」）；
  2. 订阅主题 & 初始化：Consumer 向 Broker 主节点发送订阅请求，声明要消费的 Topic 和标签（如 demo-topic:* 表示订阅所有标签），Broker 记录消费者所属的消费组信息；
  3. 拉取消息：Consumer 根据自身消费能力，定时向 Broker 主节点发送拉取请求，指定要拉取的 Topic、Queue 和消费偏移量（即 “上次消费到哪个位置”）；Broker 从 ConsumeQueue 中找到对应索引，再从 CommitLog 中读取完整消息，返回给 Consumer；
  4. 执行消费逻辑：Consumer 接收到消息后，执行业务消费逻辑（如短信发送、库存扣减、日志解析等）；
  5. 反馈消费结果：消费完成后，Consumer 向 Broker 反馈消费状态，分为两种：
    • 消费成功（CONSUME_SUCCESS）：Broker 更新该消费者的消费偏移量，记录 “已消费到该位置”，后续不再重复推送该消息；
    • 消费失败（RECONSUME_LATER）：Broker 暂不更新偏移量，等待重试时间（默认 3 秒）后，Consumer 会再次拉取该消息重试。
阶段 5：异常处理 & 兜底机制（保证消费可靠性，避免阻塞）
  1. 消费重试：单条消息消费失败后，会自动重试（默认 16 次），每次重试间隔逐渐变长（从 3 秒到数分钟），给业务足够的恢复时间；
  2. 死信队列（DLQ）：当消息重试达到最大次数仍消费失败时，Broker 会将该消息移入死信队列（专属 Topic：%DLQ%+消费组名），不再参与正常消费，避免阻塞整个消费队列；业务可单独监控死信队列，人工排查失败原因（如消息格式错误、依赖服务宕机）；
  3. Broker 故障容灾：若某个 Broker 主节点宕机，NameServer 会检测到其心跳中断，从路由表中移除该节点；后续 Producer/Consumer 拉取路由时，会获取到其他可用的 Broker 节点，消息发送 / 消费自动切换至健康节点，无单点故障；
  4. 消费进度恢复：Consumer 的消费偏移量由 Broker 持久化存储（Offset 文件），若 Consumer 节点宕机，重启后会从 Broker 拉取最新的偏移量，继续从上次消费的位置开始，实现断点续传，避免消息重复消费或丢失。

简化版：

1. 启动：NameServer→Broker（注册路由）→Producer/Consumer 2. 生产：Producer 查 NameServer 路由→发消息到 Broker 主节点→Broker 持久化+主从同步 3. 消费：Consumer 查 NameServer 路由→从 Broker 拉取消息→执行业务→反馈消费结果 4. 兜底：失败重试→死信队列→Broker 故障自动切换

图解版：

请添加图片描述
请添加图片描述
请添加图片描述
请添加图片描述

四、RocketMQ 核心特性（Java 开发适配性强）

作为 Java 原生开发的消息队列，对 Java 生态兼容性极佳，同时具备企业级核心能力：

  1. 高吞吐低延迟：基于零拷贝、异步刷盘等优化，单 Broker 可支撑百万级 TPS，消息延迟毫秒级；
  2. 高可用：Master/Slave 架构，Broker 故障时，生产者 / 消费者可通过 NameServer 切换至备用 Broker，无单点故障；
  3. 消息持久化：默认将消息存储在磁盘（CommitLog 日志文件），支持同步刷盘（强一致性）、异步刷盘（高性能），避免内存丢失；
  4. 消息可靠性：支持重试机制（消费者消费失败可自动重试）、死信队列（多次重试失败的消息进入死信队列，避免阻塞正常消费）；
  5. 分布式事务支持：提供事务消息功能，解决分布式系统中的事务一致性问题（基于「半消息 + 回查」机制）；
  6. 丰富的消息类型：普通消息、顺序消息（严格按发送顺序消费，适合订单流程）、延时消息（定时消费，适合超时未支付关单）、事务消息；
  7. 负载均衡与扩缩容：生产者 / 消费者集群可动态扩缩容，Broker 集群支持水平扩容，NameServer 无状态扩容简单；
  8. 监控与运维：提供内置监控台，支持消息轨迹追踪、消费进度监控、异常告警，适配企业级运维需求。

三、RocketMQ 与 Kafka/ActiveMQ 的对比（适用场景）

特性RocketMQKafkaActiveMQ
开发语言Java（原生适配 Java 生态）Scala/JavaJava
吞吐能力高（百万级 TPS）极高（千万级 TPS）中（万级 TPS）
延迟性能低（毫秒级）极低（微秒级）中（毫秒～秒级）
消息可靠性高（持久化 + 多副本）高（持久化 + 多副本）中（易丢消息）
功能丰富度高（顺序、延时、事务）中（仅普通消息，需扩展）中（支持 JMS，功能一般）
分布式事务原生支持不支持（需业务实现）支持（JMS 事务）
运维复杂度中（集群部署简单）高（依赖 ZooKeeper，调优复杂）低（入门简单）
适用场景企业级分布式系统（电商、金融）、异步通信、流量削峰、分布式事务大数据日志采集、流处理、高吞吐低延迟的消息传输小型系统、入门级开发、对性能要求不高的场景

核心结论：RocketMQ 是Java 分布式系统的首选消息队列之一，兼顾了高吞吐、高可用、功能丰富性和运维便捷性，比 Kafka 功能更贴合企业业务需求，比 ActiveMQ 性 能和可靠性更高。

四、Java 中使用 RocketMQ 的极简示例

1. 引入 Maven 依赖（核心依赖）

<!-- RocketMQ 客户端核心依赖 --><dependency><groupId>org.apache.rocketmq</groupId><artifactId>rocketmq-client</artifactId><version>4.9.7</version><!-- 推荐稳定版本，与服务端一致 --></dependency>

2. 生产者发送普通消息

importorg.apache.rocketmq.client.producer.DefaultMQProducer;importorg.apache.rocketmq.common.message.Message;publicclassRocketMQProducer{publicstaticvoidmain(String[] args)throwsException{// 1. 创建生产者实例，指定「生产者组」（集群消费必须指定，标识同一组生产者）DefaultMQProducer producer =newDefaultMQProducer("demo-producer-group");// 2. 设置 NameServer 地址（多个地址用;分隔） producer.setNamesrvAddr("127.0.0.1:9876");// 3. 启动生产者 producer.start();// 4. 发送消息（Topic：主题，Tag：标签（用于消息过滤），Body：消息体）Message message =newMessage("demo-topic",// 主题（需提前创建，或开启自动创建）"demo-tag",// 标签"Hello RocketMQ from Java!".getBytes()// 消息体（字节数组）);// 同步发送，返回发送结果 producer.send(message);System.out.println("消息发送成功");// 5. 关闭生产者（实际项目中建议在服务关闭时执行） producer.shutdown();}}

3. 消费者消费普通消息（集群消费模式）

importorg.apache.rocketmq.client.consumer.DefaultMQPushConsumer;importorg.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;importorg.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;importorg.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently;importorg.apache.rocketmq.common.message.MessageExt;importjava.util.List;publicclassRocketMQConsumer{publicstaticvoidmain(String[] args)throwsException{// 1. 创建消费者实例，指定「消费者组」（集群消费的核心标识）DefaultMQPushConsumer consumer =newDefaultMQPushConsumer("demo-consumer-group");// 2. 设置 NameServer 地址 consumer.setNamesrvAddr("127.0.0.1:9876");// 3. 订阅主题和标签（* 表示订阅所有标签，demo-tag||demo-tag2 表示订阅多个标签） consumer.subscribe("demo-topic","*");// 4. 设置消息监听器，处理消费逻辑 consumer.registerMessageListener((MessageListenerConcurrently)(msgs, context)->{for(MessageExt msg : msgs){// 解析消息体String content =newString(msg.getBody());System.out.printf("消费消息：topic=%s, tag=%s, content=%s%n", msg.getTopic(), msg.getTags(), content);}// 返回消费状态：CONSUME_SUCCESS（成功）、RECONSUME_LATER（重试）returnConsumeConcurrentlyStatus.CONSUME_SUCCESS;});// 5. 启动消费者（消费者启动后持续监听，无需手动循环） consumer.start();System.out.println("消费者启动成功，开始监听消息");}}

五、RocketMQ 的典型应用场景（Java 分布式系统）

  1. 异步通信：用户注册后，异步发送短信 / 邮件通知，无需等待通知发送完成再返回结果，提升接口响应速度；
  2. 流量削峰：电商秒杀、大促时，将用户请求发送至 RocketMQ，消费者按系统处理能力匀速消费，避免数据库 / 服务被压垮；
  3. 分布式事务：订单创建 + 库存扣减的分布式场景，通过事务消息保证两者要么都成功，要么都失败；
  4. 顺序消费：订单的创建、支付、发货、签收流程，需严格按顺序执行，使用 RocketMQ 顺序消息保证消费顺序；
  5. 延时任务：订单超时未支付自动关单、优惠券到期提醒，使用延时消息实现定时触发；
  6. 系统解耦：微服务架构中，订单服务、库存服务、物流服务通过 RocketMQ 通信，无需直接调用，降低服务耦合度；
  7. 日志采集：业务系统的日志异步发送至 RocketMQ，由专门的消费服务采集至 ELK 系统，不影响业务主流程。

六、核心总结

  1. RocketMQ 是 Apache 顶级开源项目，Java 原生开发，适配 Java 分布式生态，主打高吞吐、高可用、功能丰富；
  2. 核心架构由 NameServer（路由）、Broker（核心存储）、Producer（生产者）、Consumer（消费者）4 大角色组成，分布式集群无单点故障；
  3. 支持普通、顺序、延时、事务等多种消息类型，原生提供分布式事务、重试机制、死信队列等企业级特性；
  4. 对比 Kafka 更贴合企业业务需求，对比 ActiveMQ 性能更优，是Java 分布式系统的主流消息队列选择；
  5. 典型应用于异步通信、流量削峰、分布式事务、系统解耦等场景，上手简单，运维便捷。

集至 ELK 系统，不影响业务主流程。

六、核心总结

  1. RocketMQ 是 Apache 顶级开源项目，Java 原生开发，适配 Java 分布式生态，主打高吞吐、高可用、功能丰富；
  2. 核心架构由 NameServer（路由）、Broker（核心存储）、Producer（生产者）、Consumer（消费者）4 大角色组成，分布式集群无单点故障；
  3. 支持普通、顺序、延时、事务等多种消息类型，原生提供分布式事务、重试机制、死信队列等企业级特性；
  4. 对比 Kafka 更贴合企业业务需求，对比 ActiveMQ 性能更优，是Java 分布式系统的主流消息队列选择；
  5. 典型应用于异步通信、流量削峰、分布式事务、系统解耦等场景，上手简单，运维便捷。

补充：使用前需先部署 RocketMQ 服务端（NameServer + Broker），服务端部署简单，支持单机 / 集群模式，官方提供了完整的部署文档，适配 Linux/Windows 环境。

Read more

【AI应用开发工程师】-AI写代码总翻车？一文帮你解决（附实战案例）

【AI应用开发工程师】-AI写代码总翻车？一文帮你解决（附实战案例）

AI 写代码不按需求来？这个需求对齐 Skill 让你告别返工！ 引言 你是不是也遇到过这种情况：兴冲冲地给 AI 提了个需求，结果它生成的代码完全跑偏，就像你点了一份红烧肉，端上来的却是番茄炒蛋？别急，这很可能不是 AI 的锅，而是需求没对齐！今天，我就来安利一个神器—— 需求对齐 Skill 。 目录 * 什么是需求对齐模式？ * 核心原则：三大“只”字诀 * 执行流程：三步搞定需求确认 * 实际示例：视频提示词修改功能 * 如何应用这个 Skill？ * 结语：一起告别返工！ 什么是需求对齐模式？ 简单说，这是一种让 AI“先理解，后动手”的交互模式。在没有这个 Skill 之前，每次提新需求都得和 AI“聊半天”，还经常返工。

By Ne0inhk
人工智能：多模态大模型原理与跨模态应用实战

人工智能：多模态大模型原理与跨模态应用实战

人工智能：多模态大模型原理与跨模态应用实战 1.1 本章学习目标与重点 💡 学习目标：掌握多模态大模型的核心原理、跨模态特征融合方法，以及基于多模态模型的图文生成与理解任务实战流程。 💡 学习重点：理解多模态模型的架构设计，学会使用 Hugging Face 生态工具调用 CLIP 与 BLIP-2 模型，完成图文检索与图像描述生成任务。 1.2 多模态大模型的核心概念与发展背景 1.2.1 什么是多模态大模型 💡 多模态大模型是指能够同时处理文本、图像、音频、视频等多种不同类型数据的人工智能模型。它打破了传统单模态模型的信息壁垒，实现了跨模态的理解与生成。 多模态大模型的核心能力体现在两个方面： * 跨模态理解：实现不同模态数据之间的关联分析，例如根据文本描述查找对应图像、根据图像内容生成文字摘要。 * 跨模态生成：以一种模态数据为输入，生成另一种模态的数据，例如文本生成图像、图像生成文本、语音生成视频等。 与单模态大模型相比，多模态大模型更贴近人类的认知方式。人类在认识世界的过程中，本身就是通过视觉、听觉、语言等多种感官渠道接收和处理信息的。

By Ne0inhk
【鸿蒙心迹】我的HarmonyOS百宝箱

【鸿蒙心迹】我的HarmonyOS百宝箱

前言 大家好，我是万少，这个是我的自我介绍 我是一个鸿蒙应用开发技术爱好者，同时也是鸿蒙应用技术的传播者 目前牵头和扶持个人开发者开发了十几款鸿蒙上架应用了，有《可可图片编辑》、《青蓝萤火故事屋》、《自然壁纸》等等。 接下来分享一下平时我开发鸿蒙应用的百宝箱吧，希望可以助力鸿蒙应用开发爱好者。 鸿蒙应用开发官网 鸿蒙应用开发官网是所有鸿蒙应用开发者必须要熟悉和常用的地址，所有第一手鸿蒙应用开发的资料都在其中，而且是中文的，符合国人的口吻，这一点相比较与其他客户端开发，如安卓和ios等，有极大的收益，特别方便英文不太好的小伙伴 😄。 指南 指南 ，在鸿蒙应用开发官网中 是以教学的角度梳理的鸿蒙应用开发知识，也是我们初学者入门了解相关技术的入口，它会以小步骤的形式告诉你该技术如何使用，当我们搜索相关资料的时候都可以优先看这里。 API参考 API 就想一门鸿蒙应用开发的字典，它会完整详细的告诉你某段API参数的具体说明，当我们想要精确了解某个核心代码的参数、返回值等信息的时候就需要在这里进行查看。 最佳实践 最佳实践是一个初学者了解某一类业务的解决方案的绝

By Ne0inhk
内存暴涨700%背后的惊天真相：AI正在吞噬一切！能源·隐私·绿色三大维度深度拆解

内存暴涨700%背后的惊天真相：AI正在吞噬一切！能源·隐私·绿色三大维度深度拆解

🔥作者简介： 一个平凡而乐于分享的小比特，中南民族大学通信工程专业研究生，研究方向无线联邦学习 🎬擅长领域：驱动开发，嵌入式软件开发，BSP开发 ❄️作者主页：一个平凡而乐于分享的小比特的个人主页 ✨收录专栏：未来思考，本专栏结合当前国家战略和实时政治，对未来行业发展的思考 欢迎大家点赞 👍 收藏 ⭐ 加关注哦！💖💖 🔥内存暴涨700%背后的惊天真相：AI正在吞噬一切！能源·隐私·绿色三大维度深度拆解 ｜前言｜ 最近装机的小伙伴们欲哭无泪：DDR5内存价格一路狂飙，部分DRAM现货价格在过去一年暴涨近700% 。大家习惯性吐槽“厂商放火”、“产能不足”，但很少有人看到，这场涨价风暴的真正推手，是那只名为“AI”的巨兽。 当你还在为多花几百块钱买内存心疼时，国家正在西部荒漠建起一座座数据中心，科技巨头正在为“吃电怪兽”抢购每一颗芯片。2026年，大型科技公司的AI相关投资预计将达到6500亿美元，较去年增长约80% 。 今天，我们从能源供应、隐私安全、绿色AI 三个维度，结合东数西算、算电协同、

By Ne0inhk