为什么需要用消息队列

异步处理

应用解耦

流量削峰

前面几点好多文章都有介绍，这里就不再说明了。

怎样用才合理

消息过滤

在消息不频繁的情况，在 Customer 过滤也是一个比较好的选择，自由度更高

Broker 端消息过滤

优点：由 broker 端 过滤消息，减少消费端收到过多的无用消息
缺点：对 borker 有一定压力

Customer端消息过滤

优点：自由程度较高
缺点：很多无用消息会到 customer 端

message key

可给消息增加唯一标示

RocketMQ 并不能保证 message id 唯一，在这种情况下，生产者在push 消息的时候可以给每条消息设定唯一的 key, 消费者可以通过 message key 保证对消息幂等处理。
建议可以用 uuid 作为 message key

项目实战

场景：用户中心新用户，特定业务希望【用户id】能落到业务库

定义 topic

根据阿里云 RocketMQ 建议，设定 topic: T-Platform-Account

定义生产者

Producter: Pid-Platform-Account

定义 tag

前面的场景表明了 特定业务希望【用户id】能落到业务库，假设有X组产品A,产品B， Y组产品C, X，Y 两个组希望用户注册（已经携带了产品标示，但是没有直接经过业务系统）时，能收到消息。 当有来源A，B，C 3个产品的新用户时，生产者会发送tag 为 create_A, create_B, create_C 的消息， 而 X组订阅 topic 为 T-Platform-Account ，tag 为 create_A | create_B的消息，Y组订阅 topic 为 T-Platform-Account ，tag 为 create_C ，则可分别收到消息。

message key

可采用第三方 uuid 库作为 message key : 如果是 node 项目可用右边链接介绍的库https://github.com/kelektiv/node-uuid

body

考虑到用户中心存在批量创建用户的可能性，为了保证统一的消息格式, body 定义如下：

{
   user_ids: number[]
}

eg:

{
   user_ids: [1, 2, 3, 4]
}

业务方再根据需要到用户服务拉取定制化消息即可。

文档参考

十分钟入门RocketMQ
阿里云：消息幂等
阿里云：topic&tag最佳实践