01.常见消息队列介绍

1.1 RabbitMQ

• RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现
• AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全
• AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次

1.2 Kafka（高性能）

• Kafka是Linkedln开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目
• Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输
• 0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务
• kafka使用page cache进行文件存储,进而实现高性能读写关注性能，可靠性关注不高

1.3 ActiveMQ（性能一般）

• ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线，并且它一个完全支持JMS规范的消息中间件

• 其丰富的API、多种集群构建模式使得他成为业界老牌消息中间件，在中小型企业中应用广泛！

• MQ衡量指标：服务性能（一般，如果对并发要求不是特别大，可以考虑使用）、数据存储、集群架构

• 特点：

  • 1、支持多种语 言编写客户端
  • 2、对spring的支持，很容易和spring整合
  • 3、支持多种传输协议：TCP,SSL,NIO,UDP等
  • 4、支持AJAX

• 消息形式：

  • 1、点对点（queue）
  • 2、一对多（topic）

1.4 RockerMQ（收费）

• RocketMQ是阿里开源的消息中间件，目前也已经孵化为Apache顶级项目

• 它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点

• RocketMQ思路起源于Kafka，它对消息的可靠传输及事务性做了优化

• 目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景

• 特点：

  • 维护是一个痛点，需要专门的团队

  • 可以保证消息顺序性

  • 提供丰富的消息拉取和推送的模式

  • 高效的水平扩展

  • 多种架构模式可供选择：双Master,Msater-Slave,2m2s,多主多从

  • 同步双写，异步复制，存储方式，零拷贝

  • 分布式事务，主从自动切换

02.rabbitmq和kafka的区别

0、总结

• RabbitMQ适合灵活、复杂的消息路由和场景，而Kafka则更适合高吞吐量、大规模数据流处理场景

特性	Kafka	RabbitMQ
吞吐量	高（顺序写、零拷贝、分区机制）	中等（复杂路由逻辑带来开销）
消息模型	简单（Topic/Partition）	复杂（Exchange/Queue）
消费模式	拉取（Pull）	推送（Push）
保留策略	消费后保留	消费后删除，需配置TTL和死信队列
消息路由	固定（通过Topic路由）	灵活（多种Exchange类型）
高可用性	Leader选举，Zookeeper管理	镜像队列、集群支持

1、功能区别

1）吞吐量：Kafka的吞吐量更高

• Kafka的设计目标是高吞吐量、大数据流处理，因此它在吞吐量方面表现优越，主要通过以下几种机制来实现

• Zero Copy机制：
  • Kafka通过Linux的Zero Copy技术实现了数据的高效传输
  • 数据从磁盘读取后直接拷贝到网络设备，而不必经过内核态和用户态的切换
  • 减少了数据拷贝的次数和上下文切换，提高了吞吐量
• 磁盘顺序读写：
  • Kafka将消息持久化到磁盘，但由于其顺序写入的设计，大幅减少了磁盘的寻道时间，读写性能更高
  • 相对于随机读写的开销，这种顺序读写的方式更加高效
• 批量处理机制：
  • Kafka支持批量写入与批量消费，生产者可以将多条消息打包成一批发送，消费者也可以通过批量拉取消息来提高处理效率
  • 这样减少了频繁网络请求的开销，提升了系统整体的吞吐能力
• 存储复杂度低：
  • Kafka的存储机制具备**O(1)**的复杂度，消息的读写性能稳定且高效
  • 即使在消息规模庞大的场景下，Kafka仍能保证较快的响应速度
  • 消息的读写性能通过分区（Partition）和分段（Segment）管理得以提升
• 分区机制：
  • Kafka的每个Topic可以被分为多个Partition，允许消息并行处理
  • 分区机制不仅提高了消息的并发处理能力，还为Kafka带来了更高的吞吐量

2）可靠性：RabbitMQ更可靠

• RabbitMQ采用了严格的消息确认机制和多种策略来确保消息的可靠性

• 消息确认机制：
  • RabbitMQ通过生产者和消费者两端的ACK确认机制，确保消息从生产者成功发送到队列，从队列正确消费到消费者
  • 消息未被正确消费时，会重新回到队列中等待重新消费
• 事务支持：
  • RabbitMQ支持事务机制，但由于事务操作会增加系统开销和延迟，生产环境中不常用
  • 通过事务可以确保消息的完整性与可靠传递
• 回调和备份交换器：
  • RabbitMQ通过委托机制和备份交换器（Alternate Exchange）
  • 当消息无法路由时，会触发相应的回调，或将消息发送到备份交换器以确保消息不会丢失

3）高可用性

• RabbitMQ：
  • 镜像队列（Mirror Queue）：
    • RabbitMQ通过镜像队列来提供高可用性，主节点（Master）和从节点（Slave）同步数据
    • 当主节点收到消息时，消息会被同步到所有镜像队列
    • 只有当所有从节点都成功接收消息时，才会返回ACK，确保了数据的一致性与高可用性
  • 集群模式：
    • RabbitMQ的高可用集群模式通过分布式节点来实现
    • 当一个节点失效时，其他节点可以继续接收和处理消息，保持服务的可用性
• Kafka：
  • 分区副本机制：
    • Kafka的每个Partition可以有多个副本，这些副本存储在不同的Broker节点上
    • 主副本（Leader）负责消息的写入操作，其他副本（Follower）从Leader拉取数据并进行同步
  • Zookeeper的Leader选举：
    • Kafka通过Zookeeper管理集群的元数据和Leader选举
    • 当某个Broker故障时，Zookeeper会重新选举新的Leader来保持集群的正常运行
    • 生产者和消费者可以通过Zookeeper获取最新的Leader信息
  • 同步与异步复制：
    • Kafka支持同步和异步复制
    • 同步复制能够保证数据在多个副本上成功存储后才确认消息，确保高可靠性
    • 异步复制则允许在某些情况下牺牲数据一致性以换取更高的性能

3）负载均衡

• Kafka：
  • 基于分区的负载均衡：
    • Kafka的负载均衡通过Topic的Partition实现
    • 每个Topic可以分成多个Partition，生产者可以将消息发送到不同的Partition
    • 消费者组中的不同消费者也可以从不同的Partition中并行消费消息，从而实现高效的负载均衡
  • Zookeeper协调：
    • Kafka依赖Zookeeper来协调集群中Broker和Partition的负载均衡
    • 当新增Broker或消费者时，Zookeeper会动态调整Partition的分配，确保负载均衡
• RabbitMQ：外部负载均衡机制
  • RabbitMQ的负载均衡机制需要借助外部工具如Keepalive和HAProxy来实现
  • RabbitMQ本身不提供和Kafka类似的分区机制，而是通过多个队列来分发负载

2、消息模型

1）Kafka：基于Topic的发布/订阅模式

• Kafka采用发布/订阅模型（Pub/Sub），生产者将消息发送到Topic，多个消费者可以订阅同一个Topic中的消息
• 消费者可以选择从何处开始消费消息（包括从历史消息中拉取），这是Kafka与RabbitMQ消息模型的一个显著区别

2）RabbitMQ：基于交换机的消息路由

• RabbitMQ通过**交换机（Exchange）**将消息从生产者路由到相应的队列
• 交换机的多样性（Direct、Fanout、Topic、Headers）提供了灵活的消息路由方式
• 生产者发送消息给交换机后，交换机根据绑定规则（Binding）决定如何将消息分发到队列中

3、消息顺序保证

• Kafka：
  • Kafka通过Partition保证消息的顺序性
  • 每个Partition内部的消息是有序的，生产者可以选择某个特定的Partition发送消息，以保证某个Topic分区内的消息顺序不变
• RabbitMQ
  • RabbitMQ通过队列来保证消息的顺序性
  • 队列内的消息是严格按照FIFO顺序处理的，确保先入队的消息优先被消费

4、消费模式

• Kafka：
  • Kafka的消费者采用**拉模式（Pull）**来主动从Broker中拉取消息
  • 消费者可以根据自身的处理能力动态控制拉取的速率，从而实现对消息的批量处理
• RabbitMQ：
  • RabbitMQ支持推模式（Push），Broker主动将消息推送给消费者
  • 消费者可以通过配置Qos（质量服务）机制限制消息的推送速率，从而避免因消费能力不足而导致的消息堆积

5、消息保留策略

• Kafka：
  • Kafka通过配置消息保留时间（Retention Policy）来决定消息的保存时长
  • 即使消息已经被消费，Kafka也会将其保留一段时间，便于后续查询或重新消费
• RabbitMQ：
  • RabbitMQ的消息一旦被消费，默认会被删除
  • 如果需要保留消息，需要额外设置**TTL（Time-To-Live）或死信队列（DLX）**机制

03.RabbitMq与Redis队列

3.1 RabbitMQ与Redis作用

• 1.RabbitMQ:RabbitMQ是一个可以在不同程序间共享数据的代理，是实现AMQP（高级消息队列协议）的消息中间件的一种

• 2.Redis:是一个Key-Value的NoSQL数据库

3.2 具体对比

• 1.可靠消费

  • Redis：没有相应的机制保证消息的消费，当消费者消费失败的时候，消息体丢失，需要手动处理
  • RabbitMQ：具有消息消费确认，即使消费者消费失败，也会自动使消息体返回原队列，同时可全程持久化，保证消息体被正确消费

• 2.可靠发布

  • Reids：不提供，需自行实现

  • RabbitMQ：具有发布确认功能，保证消息被发布到服务器

• 3.高可用

  • Redis：采用主从模式，读写分离，但是故障转移还没有非常完善的官方解决方案
  • RabbitMQ：集群采用磁盘、内存节点，任意单点故障都不会影响整个队列的操作

• 4.持久化

  • Redis：将整个Redis实例持久化到磁盘
  • RabbitMQ：队列，消息，都可以选择是否持久化

• 5.应用场景分析

  • Redis：轻量级，高并发，延迟敏感即时数据分析、秒杀计数器、缓存等
  • RabbitMQ：重量级，高并发，异步批量数据异步处理、并行任务串行化，高负载任务的负载均衡等行任务串行化，高负载任务的负载均衡等