消息队列

综合问题

为什么使用消息队列

• 异步
• 解耦
• 削峰

有哪些消息队列

• ActiveMQ 老牌产品
• RabbitMQ 流行，ERLang编写，成熟稳定，自带的管理界面较好用
• RocketMQ 阿里出品，java编写，成熟度上不如RabbitMQ
• kafka 吞吐量大，一般用作大数据处理，比如日志处理

RabbitMQ

基本概念

• exchange 路由，消息是发送给某一个路由
• queue 队列，实际存储数据，读数据是从某一个队列读取
• binding 把路由和queue绑定出来，按一定规则作分发
• routing key 一个关键字，按照key来作不同的分发
• channel 信道

分发模式

• direct 点对点，按routing key完全匹配来分发
• fanout 广播模式，不需要 routing key，直接复制
• topic 按routing 模糊匹配来分发 * 一个单词，# 号零个或多个单词
• headers 根据消息本身的header来匹配

高可用

• 单机模式
• 普通集群模式，queue只放在一个实例上，其它实例同步queue的元信息，需要时再去取
• 镜像集群模式，同步queue的元信息和数据信息

问题

• 保证消息有序
  • 拆分多个queue，每个queue一个consumer
  • 只有一个queue和一个consumer，consumer再通过内部队列作有序处理
• 保证消息不重复
  • 业务层需要幂等
• 保证消息不丢失
  • 发送成功：开启发送确认模式
  • 存储时不丢失：开启持久化
  • 消费成功：开启消息的确认模式
• 消息大量积压如何处理
  • 加快消费：扩容consumer
  • 临时导出：把队列数据临时导出来，等资源不紧张了再处理
  • 丢弃数据：高峰过去后，想办法让发送方再触发一次

kafka

选型

首先看是否是用于大数据量传输，是否有大量堆积。比如大批量的日志传输、大批量的机器信息采集。如果是则采用kafka，单机吞吐量在10万级。缺点是有部署起来稍微复杂，需要zookeeper，其次功能相对简单，延迟性不如RabbitMq

如果是传统的消息队列，不需要做二次开发，一般选用 rabbitMq，成熟稳定功能丰富，同时延迟也是最低的。如果需要二次开发，则选用阿里出品的RocketMq