大家好，我是晚安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 查回来：
// 单批 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;
}
<!-- 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 的消息，永远取模进同一个队列：
// 同一 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，没管生产端发到哪个队列。结果消息被散到随机队列，消费出来完全乱序，改完的头像又变回旧的。盯着日志愣了半天——好家伙，顺序消费是消费端的事，但顺序能不能成立，生产端先说了算。
消费端注册顺序监听器，让同一个队列只被单线程串行消费：
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 写批量写缓存，代码很直白：
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，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你做用户数据同步时，遇到过哪些乱序或者写入慢的坑？
