RabbitMQ实战经验总结

1.资源管理

队列到底是消费者创建还是生产者创建？
答案是：消费者创建 （谁使用谁管理，谁污染谁治理）

交换机和队列，实际上是作为资源，由运维管理员创建的。
为什么仍然需要在代码中定义？重复创建不报错吗？（重复定义不会报错）

2. 配置文件与命名规范

1. 元数据的命名集中放在 properties 文件中，不要用硬编码。
   如果有多个系统，可以配置多个 xxx_mq.properties。
2. 命名体现元数据的类型
   虚拟机命名： XXX_VHOST
   交换机命名：XXX_EXCHANGE
   队列命名：_QUEUE
3. 命名体现数据来源和去向
   例如：销售系统发往产品系统的交换机：SALE_TO_PRODUCT_EXCHANGE。做到见名知义，不用去查文档（当然注释是必不可少的）。

3. 信息落库+定时任务

将需要发送的消息保存在数据库中，可以实现消息的可追溯和重复控制，需要配合定时任务来实现。

1. 将需要发送的消息登记在消息表中。
2. 定时任务一分钟或半分钟扫描一次，将未发送的消息发送到 MQ 服务器，并且修改状态为已发送。
3. 如果需要重发消息，将指定消息的状态修改为未发送即可。

副作用：降低效率，浪费存储空间。

4. 日志追踪

RabbitMQ 可以通过 Firehose 功能来记录消息流入流出的情况，用于调试，排错。它是通过创建一个 TOPIC 类型的交换机（amq.rabbitmq.trace），把生产者发送给Broker 的消息或者 Broker 发送给消费者的消息发到这个默认的交换机上面来实现的。另外 RabbitMQ 也提供了一个 Firehose 的 GUI 版本，就是 Tracing 插件。启用 Tracing 插件后管理界面右侧选项卡会多一个 Tracing，可以添加相应的策略。RabbitMQ 还提供了其他的插件来增强功能。

5. 如何减少连接数

在发送大批量消息的情况下，创建和释放连接依然有不小的开销。我们可以跟接收方约定批量消息的格式，比如支持 JSON 数组的格式，通过合并消息内容，可以减少生产者/消费者与 Broker 的连接。比如：活动过后，要全范围下线产品，通过 Excel 导入模板，通常有几万到几十万条解绑数据，合并发送的效率更高。

建议单条消息不要超过 4M（4096KB），一次发送的消息数需要合理地控制。