RocketMQ 顺序消费实战：批量接口加 Redis Pipeline同步数据

大家好，我是晚安code。

用户信息同步：用户改昵称、换头像，变更要实时同步给下游的搜索和排行榜。量一上来，三个问题全冒头------查用户信息慢到两秒起，消息消费出来顺序乱得离谱，改完的头像刚写进缓存又被旧数据盖回去。最后是 RocketMQ 顺序消费 + 批量接口 + Redis Pipeline 三件套把整条链路救活的。这套组合拳怎么打、坑在哪里，下面一次讲透。点个收藏，我们开始~

一、三个痛点：乱和慢都出在三个固定环节

（2026 年 7 月实测，示例基于 RocketMQ 经典客户端 API，4.x/5.x 通用）

用户信息同步 90% 的故障，都来自「查得碎、传得乱、写得慢」这三个环节。

1）查得碎：N+1 查询。批量接口服务拿到一批用户 ID，传统写法是 for 循环一个 ID 查一次库，100 个用户就是 100 条 SQL。 2）传得乱：消息乱序。用户改了昵称又改头像，两条消息要是被消费端抢着处理，顺序一乱，旧数据就把新数据盖回去了。 3）写得慢：缓存写放大。同步结果写 Redis，一条一条 set，每一条都是一次网络往返。

下面按「查、传、写」的顺序，一个一个治。

二、批量获取用户信息接口：先把 N+1 干掉

N+1 查询：业务层先查一次拿到 ID 列表，再对每个 ID 单独查一次数据库，循环里每走一遍就发一条 SQL。你可以理解为「点一桌菜，每道菜单独跑一趟店」。

批量接口解决的就是 N+1------一次 IN 查询拿回整批用户，数据库往返能省掉 99%。核心逻辑很简单：把 ID 列表分批，每批用一条 IN 查回来：

java 复制代码

// 单批 500，分批拉取，避免 IN 条件一次塞太多
public List<UserInfo> batchGetUsers(List<Long> userIds) {
    List<UserInfo> result = new ArrayList<>();
    for (int i = 0; i < userIds.size(); i += 500) {
        List<Long> sub = userIds.subList(i, Math.min(i + 500, userIds.size()));
        result.addAll(userMapper.selectByIds(sub));
    }
    return result;
}

xml 复制代码

<!-- WHERE id IN (...) 一次拿回整批 -->
<select id="selectByIds" resultType="UserInfo">
    SELECT * FROM user_info WHERE id IN
    <foreach collection="ids" item="id" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

有个坑我得先交代：我第一次写这个接口，一股脑把一万个用户 ID 全塞进 IN，MySQL 预编译直接报错。原来预编译参数占位符有上限（默认 65535 个），塞得越多越容易踩线，单批控制在 500 到 1000 是安全经验值。

批量查询还有两个细节别漏：一是查出来的结果可能缺用户（已注销、数据被删），要处理 null，别让下游拿着 null 去拼业务；二是接口要做批次上限和限流，外部传进来十万个 ID 不能照单全收。

三、RocketMQ 顺序消费：同一批用户的消息不能乱

RocketMQ 顺序消息：指消息的发送顺序和消费顺序一致。RocketMQ 默认不保证顺序，只有把同一业务 key 的消息路由进同一个消息队列（MessageQueue），再让消费端串行消费这个队列，顺序才成立。可以理解为「一条队伍只办一种业务，后来的人永远排在前面的人后面」。

顺序消费不是 RocketMQ 开箱即用的能力，它要生产端选队列、消费端串行两条腿同时走，少一条顺序就塌。先看两种做法的差别：

方案	实现方式	吞吐	适用场景
全局顺序	队列数设 1，单线程收发	低，接近单机	极少用的全量同步
局部顺序	业务 key 路由同一队列，队列内串行	高，可水平扩展	订单/用户维度要求顺序

生产端的关键是 MessageQueueSelector------同一 uid 的消息，永远取模进同一个队列：

java 复制代码

// 同一 uid 的消息固定发到同一个队列
SendResult result = producer.send(msg, new MessageQueueSelector() {
    @Override
    public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
        Long uid = (Long) arg;
        return mqs.get((int) (uid % mqs.size()));
    }
}, userId);

看下图 2：不同用户的消息被分到不同队列并行消费，但每个队列内部是严格串行的。这就是局部顺序的精髓------顺序保住了，吞吐也没丢。

我第一次做顺序消费，只加了 MessageListenerOrderly，没管生产端发到哪个队列。结果消息被散到随机队列，消费出来完全乱序，改完的头像又变回旧的。盯着日志愣了半天------好家伙，顺序消费是消费端的事，但顺序能不能成立，生产端先说了算。

消费端注册顺序监听器，让同一个队列只被单线程串行消费：

java 复制代码

consumer.registerMessageListener(new MessageListenerOrderly() {
    @Override
    public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs,
                                               ConsumeOrderlyContext context) {
        handle(msgs); // 同一队列内串行执行
        return ConsumeOrderlyStatus.SUCCESS;
    }
});

几个注意点记一下：消费失败要返回 SUSPEND_CURRENT_QUEUE_A_MOMENT，让本队列暂停片刻本地重试（默认最多 16 次），别直接跳过；局部顺序只在集群模式（CLUSTERING）下有效，广播模式不支持；一个队列同一时刻只有一个消费线程，顺序 key 按业务维度（比如 uid）选，别太粗也别太细。

可能有人会问：加个 MessageListenerOrderly 顺序就稳了吗？

不一定。消费端串行只是必要条件，生产端必须用 MessageQueueSelector 把同一业务 key 的消息发进同一个队列，顺序才成立。两条腿缺一条都会乱。

四、Redis Pipeline：别一条条写了

Redis Pipeline（管道）：Redis 客户端把一批命令攒在一起，一次网络往返全部发给服务端，再一次性读回所有结果。你可以理解为「一次点齐一桌菜，后厨一次性上齐，而不是上一道喊一次」。

Pipeline 提的是吞吐，不是一致性------它优化的是网络传输，不是事务。三种写法怎么选，看这张表：

方式	网络往返	原子性	适用
逐条命令	N 条 N 次 RTT	每条独立	命令少、实时性高
Pipeline	N 条约 1 次 RTT	不保证，失败不回滚	批量写缓存、预热
MULTI/EXEC 事务	N 条约 1 次 RTT	原子执行	必须整体成功

用 Spring Data Redis 写批量写缓存，代码很直白：

java 复制代码

List<Object> results = redisTemplate.executePipelined(
    new SessionCallback<List<Object>>() {
        @Override
        public List<Object> execute(RedisOperations ops) {
            for (UserInfo u : userList) {
                ops.opsForValue().set("user:" + u.getId(), JSON.toJSONString(u));
            }
            return null;
        }
    });

这里我也翻过车：我把 pipeline 当事务用，一批里既有写又有读，结果读到的是旧值，数据直接对不上。pipeline 里的命令是逐条执行的，不是原子整体------中间哪条失败了，前面成功的也不会回滚。

另外三个注意点：pipeline 期间连接被独占，别在管道里夹其他操作，要同时干别的就单独开一条连接；单批别塞太多，几千上万条会把 Redis 内存和客户端响应队列顶爆，我习惯 1000 条一批；命令之间有依赖（先 GET 再 SET）不能用 pipeline，改用 Lua 脚本让服务端原子执行。

可能有人会问：pipeline 和事务是一回事吗？

不是。pipeline 只合并网络往返，命令照样一条条执行，失败不回滚；事务靠 MULTI/EXEC 保证整体执行，才是原子操作。

五、三件套串起来：一次用户信息同步的完整链路

批量接口、顺序消费、Redis 管道不是三个孤立技巧，它们各管一段，拼起来才是完整的一条同步链路。看图 1：业务提交变更 → 批量接口服务用 IN 一次拿回整批用户 → 发顺序消息（同 uid 进同队列）→ 消费端按队列串行处理 → Redis Pipeline 批量写缓存 → 同步下游搜索和排行榜。

六、复盘：三件套各治哪一环

这三件套的分工其实很清晰：批量接口治「查得碎」，RocketMQ 顺序消费治「传得乱」，Redis Pipeline 治「写得慢」。

批量接口：数据库往返从 N 次压到 N/500 次
RocketMQ 顺序消费：把「同 uid 先改后改必须按顺序」变成硬约束
Redis Pipeline：缓存写入从 N 次 RTT 压到约 1 次

说到底，这三件套没有一件是玄学，但把「查得碎、传得乱、写得慢」挨个治一遍，用户信息同步这条链路才真正稳得住。RocketMQ 顺序消费尤其提醒我一句：光盯着消费端代码，永远找不到顺序问题的根子，生产端怎么选队列才是第一步。

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你做用户数据同步时，遇到过哪些乱序或者写入慢的坑？