常见消息队列的区别与选型
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量(单机1秒处理的请求) | 万级 | 万级 | 十万级 | 十万级(kafka最大的特点) |
| Topic数量对吞吐的影响 | topic可以达到几百、几千个，吞吐量会有小幅度下降 | 几十到几百个的时候，吞吐量会大幅度下降 | ||
| 数据从生产到能消费到的延迟 | 毫秒级 | 微秒级(rabbitMQ最大的特点) | 毫秒级 | 毫秒级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高，分布式架构，一份数据可以有多个副本，少数机器宕机不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢数据 | 经过参数优化配置，可以做到零丢失 | 经过参数优化配置，可以做到零丢失 | |
| 功能支持 | MQ领域的功能极其完备 | 基于erlang开发，所以并发能力很强，性能极好，延迟很低 | MQ功能较为完善，并且是分布式的，扩展性好 | 功能较为简单，主要在大数据实时计算以及日志采集场景中被大规模使用，是事实上的标准 |
| 优劣势总结 | 非常成熟，功能强大，在业内很多公司以及项目都有应用 存在较低概率的数据丢失问题 目前社区以及国内应用越来越少，且官方社区对ActiveMQ 5.x 维护也越来越少，目前下一代的 ActiveMQ 出了新的项目叫 ActiveMQ Artemis。 一般主要用于解耦和异步，较少在吞吐量大的场景使用 |
erlang 语言开发，性能极好，延迟很低 开源提供的管理界面非常棒，很好用 社区相对活跃 问题也是显而易见的，吞吐量低一些，实现的机制比较重。erlang开发，不太好定制修改源码。并且集群动态扩展比较麻烦，主要是erlang语言本身带来的问题。 |
阿里开源的，接口简单易用 日处理消息上百亿之多，可以做到大规模吞吐，性能非常好，分布式扩展也很方便，可靠性可用性都ok，可以支持大量topic的场景，支持复杂MQ业务场景 缺点就是阿里的开源的项目，如果这个技术被内部放弃了，社区可能会黄掉 |
提供的功能比较简单，就是生产和消费，但吞吐量超高，可以任意扩展，可用性有保障，非常适合大数据领域实时计算和日志采集场景，是大数据领域的事实标准，但是消息可能会重复，需要自己处理 |
引入消息队列的优点
- 解耦：各模块之间的交互可以替换成都和MQ交互，以达到解耦的目的
- 异步：模块将请求或者数据发送给MQ之后就可以返回了，响应时间减少
- 消峰：在请求量比较打的时候可以先发送到MQ做缓冲，由消费者控制消费速率，避免大量请求直接将服务压垮
引入消息队列的缺点
- 系统复杂性增加
- 可用性降低，引入 MQ 的单点问题，需保证 MQ 高可用
- 重复数据问题
- 数据丢失问题
- 保证数据消费的顺序性
- 数据的一致性
- 由于消费者服务挂掉导致的消息队列数据积压问题
如何保证消息队列的高可用
RabbitMQ
基于主从做高可用，它有三种模式
- 单机模式：Demo
- 普通集群模式(类似于Shard): 多个机器上安装多个实例，如果创建一个新的queue，它的实际数据只会在一个实例上，但是所有实例都会有这个queue的元数据，请求来了会转发到拥有实际的实例。既不是高可用也不是分布式，只是简单的通过分散queue到不同实例增加吞吐量。
- 可能会在集群内部产生大量的数据传输
- 没什么高可用可言
- 镜像集群模式(Replica):
