消息队列分类

消息队列技术的应用

1、解耦：消息队列要解决本质问题

2、广播模式：消息队列的基本功能之一，有了消息队列，只需要关心消息是否送达了队列，至于谁需要订阅，是下游消费者的事情，极大地减少了开发和联调的工作量

3、错峰和控流：秒杀业务用于流量削峰场景（流量削峰）

4、最终一致性：最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。这不是消息队列的必备特性，但可以借此实现最终一致性问题

 

消息队列分类

ActiveMQ、Kafka、RocketMQ、RabbitMQ

这里不对ActiveMQ进行相关对比

 

Kafka

性能卓越：号称大数据的杀手锏，吞吐量极高，单机写入tps约在百万条/秒，

时效性：ms级

可用性：非常高（分布式，一个数据多个副本，少数服务宕机，不会丢失数据，不会导致不可用），控制高可用的粒度是放在分区上。每个topic的leader分区和replica分区都可以在所有broker上负载均衡的存储

消费方式：消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次

应用：一个较好的日志文件系统

功能支持：主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，功能较为简单

事务：Kafka从0.11版本开始支持事务消息，除支持最终一致性外，还实现了消息Exactly Once语义（单个partition）

回溯消费：Kafka需要先根据时间戳找到offset，然后从offset开始消费

存储形式：采用partition，每个topic的每个partition对应一个文件。顺序写入，定时刷盘。但一旦单个broker的partition过多，则顺序写将退化为随机写，Page Cache脏页过多，频繁触发缺页中断，性能大幅下降

 

缺点：

① 单机超过64个分区/队列，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长

② 消费失败不支持自动重试，（如果要重试，需要在业务系统更改offset重新拉取）

③ 支持消息顺序，但是一台代理宕机后，就会产生消息乱序

④ 社区活跃性不高，文档不足

⑤ 不支持延迟消费

总结：基于Pull的模式来处理消息消费，追求高吞吐量，时效行高，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务

 

RocketMQ

应用：用 Java 语言实现，在设计时参考了 Kafka，广泛应用在订单、交易、重置、日志流式处理、binglog分发等场景

时效：ms级

性能：单机吞吐量达10万级，支持10亿级的消息堆积，且性能不会因消息堆积而下降，性能卓越

可用性：非常高（分布式，一个数据多个副本，少数服务宕机，不会丢失数据，不会导致不可用），在高可用设计上粒度只控制在Broker。其保证高可用是通过master-slave主从复制来解决的

功能支持：mq功能较为完善，分布式架构，扩展性好

事务：RocketMQ支持事务消息，采用二阶段提交+broker定时回查。但也只能保证生产者与broker的一致性，broker与消费者之间只能单向重试。即保证的是最终一致性

回溯消费：支持按照时间回溯消费，实现原理与Kafka相同

延迟消费：支持固定延时等级的延时消息，等级可配置

存储形式：RocketMQ采用CommitLog+ConsumeQueue，单个broker所有topic在CommitLog中顺序写，Page Cache只需保持最新的页面即可。同时每个topic下的每个queue都有一个对应的ConsumeQueue文件作为索引。ConsumeQueue占用Page Cache极少，刷盘影响较小

 

缺点：社区活跃度一般，支持的客户端语言不多

总结：适用于可靠性要求很高的场景，尤其是电商、业务削峰、大流量交易涌入后端可能无法及时处理的场景，经过阿里的双11多次验证

 

RabbitMQ

吞吐量：万级，相对RocketMQ和Kafka稍显不足

时效：us级

性能：健壮、稳定、易用、跨平台、支持多种语言

缺点：源码不易阅读，学习成本较高，不利于二次开发和维护，吞吐量稍低

总结：数据量没有那么大，小公司优先选择功能比较完备的RabbitMQ