“分类:MQ”的版本间差异

来自Wikioe
跳到导航 跳到搜索
（建立内容为“<div align="center"><span style="color:black; font-weight:bold; font-size:150%;">消息中间件</span></div> == 关于 ==”的新页面）
 
无编辑摘要
第2行： 第2行：


== 关于 ==
== 关于 ==
=== 系统间通信方式？ ===
一种是基于'''远程过程调用'''的方式（如 '''RPC''' 调用）；另一种是基于'''消息队列'''的方式。
=== 什么是MQ？ ===
== 选型 ==
总的来说：
* 中小型软件公司，建议选 RabbitMQ；
* 大型软件公司，根据具体使用在 RocketMQ 和 Kafka 之间二选一。
** 根据业务场景选择，如果有大数据、日志采集功能，首选 Kafka。
=== 有哪些MQ？ ===
# '''ActiveMQ'''：是 Apache 出品的、采用 '''Java''' 语言编写的完全基于JMS1.1规范的面向消息的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。
#: 不过由于历史原因包袱太重，目前市场份额没有后面三种消息中间件多，其最新架构被命名为 Apollo，号称下一代 ActiveMQ，有兴趣的同学可行了解。
# '''RabbitMQ'''：是采用 '''Erlang''' 语言实现的 '''AMQP''' 协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。
#: RabbitMQ 发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。
# '''Kafka'''：起初是由 LinkedIn 公司采用 '''Scala''' 语言开发的一个分布式、多分区、多副本且基于 '''Zookeeper''' 协调的分布式消息系统，现已捐献给 Apache 基金会。
#: 它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。
#: 目前越来越多的开源分布式处理系统，如：Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。
# '''RocketMQ'''：是'''阿里'''开源的消息中间件，目前已经捐献个 Apache 基金会，它是由 '''Java''' 语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点。
#: 经历过双11的洗礼，实力不容小觑。
# '''ZeroMQ'''：号称史上最快的消息队列，基于 '''C''' 语言开发。
#: ZeroMQ是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩，虽然大多数时候我们习惯将其归入消息队列家族之中，但是其和前面的几款有着本质的区别，ZeroMQ本身就不是一个消息队列服务器，更像是一组底层网络通讯库，对原有的Socket API上加上一层封装而已。
=== 不同MQ的特点对比？ ===
没有最好的消息中间件，只有最合适的消息中间件：
: [[File:MQ对比1.png|400px]]
: [[File:MQ对比2.png|400px]]
* 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。
* ActiveMQ、RabbitMQ 与 Kafka、RocketMQ 有很大的区别就是前2个只支持主从模式，后2个是分布式消息系统，支持分布式。
=== Kafka 与 RocketMQ ===
官方提供了一些不同于kafka的对比差异：
* 来自：[https://rocketmq.apache.org/docs/motivation/ https://rocketmq.apache.org/docs/motivation/]
{| class="wikitable"
! !! ActiveMQ !! Kafka !! RocketMQ
|-
| '''Client SDK'''
| Java, .NET, C++ etc.
| Java, Scala etc.
| Java, C++, Go
|-
| '''协议和规范'''
| '''推'''送模型，支持OpenWire、STOMP、AMQP、MQTT、JMS
| '''拉'''模型，TCP协议支持
| '''拉'''模型，支持TCP、JMS、OpenMessage
|-
| '''消息有序'''
| 独占消费者或独占队列可以确保有序
| 确保分区内消息的顺序
| 确保消息严格有序，并可以正常扩展
|-
| '''定时消息'''
| 支持
| 不支持
| 支持
|-
| '''批量消息'''
| 不支持
| 支持，具有异步生产者（producer）
| 支持，具有同步模式，可避免消息丢失
|-
| '''广播信息'''
| 支持
| 不支持
| 支持
|-
| '''消息过滤器'''
| 支持
| 支持，您可以使用Kafka流（Streams）来过滤消息
| 支持，基于SQL92的属性过滤器表达式
|-
| '''服务器触发的重新交付'''
| 不支持
| 不支持
| 支持
|-
| '''消息存储'''
| 使用 JDBC 以及高性能日志（例如levelDB，kahaDB），支持非常快速的持久性
| 高性能的文件存储
| 高性能和低延迟的文件存储
|-
| '''消息追溯'''
| 支持
| 支持偏移追溯
| 支持的时间戳和偏移量追溯
|-
| '''消息优先级'''
| 支持
| 不支持
| 不支持
|-
| '''高可用性和故障转移'''
| 支持，取决于存储，如果使用levelDB，则需要ZooKeeper服务器
| 支持，需要ZooKeeper服务器
| 支持，主从模式，无其他套件
|-
| '''消息跟踪'''
| 不支持
| 不支持
| 支持
|-
| '''配置'''
| 默认配置为低级别，用户需要优化配置参数
| Kafka使用键值对（key-value）格式进行配置。这些值可以通过文件或编程方式提供。
| 开箱即用，用户只需注意几个配置
|-
| '''管理和操作工具'''
| 支持
| 支持，使用终端命令显示核心指标
| 支持丰富的web和终端命令以显示核心指标
|}
RocketMQ 具有以下特点：
* 能够保证'''严格的消息顺序'''
* 提供针对消息的过滤功能
* 提供丰富的消息拉取模式
* 高效的订阅者水平扩展能力
* '''实时'''的消息订阅机制
* 亿级'''消息堆积'''能力
缺点：
* 社区活跃度一般
* 没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码
Kafka 具有以下特点：
* '''快速持久化'''：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
* '''高吞吐'''：在一台普通的服务器上既可以达到10W/s的吞吐速率；
* '''高堆积'''：支持topic下消费者较长时间离线，消息堆积量大；
* 完全的'''分布式'''系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
* 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
缺点：
* Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
* 使用短轮询方式，实时性取决于轮询间隔时间；
* 消费失败不支持重试；
* 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；

2021年5月15日 (六) 04:06的版本

消息中间件

关于

系统间通信方式？

一种是基于远程过程调用的方式（如 RPC 调用）；另一种是基于消息队列的方式。

什么是MQ？

选型

总的来说：

  • 中小型软件公司，建议选 RabbitMQ；
  • 大型软件公司，根据具体使用在 RocketMQ 和 Kafka 之间二选一。
    • 根据业务场景选择，如果有大数据、日志采集功能，首选 Kafka。

有哪些MQ？

  1. ActiveMQ：是 Apache 出品的、采用 Java 语言编写的完全基于JMS1.1规范的面向消息的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。
    不过由于历史原因包袱太重，目前市场份额没有后面三种消息中间件多，其最新架构被命名为 Apollo，号称下一代 ActiveMQ，有兴趣的同学可行了解。
  2. RabbitMQ：是采用 Erlang 语言实现的 AMQP 协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。
    RabbitMQ 发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。
  3. Kafka：起初是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 Zookeeper 协调的分布式消息系统，现已捐献给 Apache 基金会。
    它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。
    目前越来越多的开源分布式处理系统，如：Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。
  4. RocketMQ：是阿里开源的消息中间件，目前已经捐献个 Apache 基金会，它是由 Java 语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点。
    经历过双11的洗礼，实力不容小觑。
  5. ZeroMQ：号称史上最快的消息队列，基于 C 语言开发。
    ZeroMQ是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩，虽然大多数时候我们习惯将其归入消息队列家族之中，但是其和前面的几款有着本质的区别，ZeroMQ本身就不是一个消息队列服务器，更像是一组底层网络通讯库，对原有的Socket API上加上一层封装而已。

不同MQ的特点对比？

没有最好的消息中间件，只有最合适的消息中间件：

MQ对比1.png
MQ对比2.png
  • 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。
  • ActiveMQ、RabbitMQ 与 Kafka、RocketMQ 有很大的区别就是前2个只支持主从模式，后2个是分布式消息系统，支持分布式。

Kafka 与 RocketMQ

官方提供了一些不同于kafka的对比差异：

ActiveMQ Kafka RocketMQ
Client SDK Java, .NET, C++ etc. Java, Scala etc. Java, C++, Go
协议和规范 推送模型，支持OpenWire、STOMP、AMQP、MQTT、JMS 拉模型，TCP协议支持 拉模型，支持TCP、JMS、OpenMessage
消息有序 独占消费者或独占队列可以确保有序 确保分区内消息的顺序 确保消息严格有序，并可以正常扩展
定时消息 支持 不支持 支持
批量消息 不支持 支持，具有异步生产者（producer） 支持，具有同步模式，可避免消息丢失
广播信息 支持 不支持 支持
消息过滤器 支持 支持，您可以使用Kafka流（Streams）来过滤消息 支持，基于SQL92的属性过滤器表达式
服务器触发的重新交付 不支持 不支持 支持
消息存储 使用 JDBC 以及高性能日志（例如levelDB，kahaDB），支持非常快速的持久性 高性能的文件存储 高性能和低延迟的文件存储
消息追溯 支持 支持偏移追溯 支持的时间戳和偏移量追溯
消息优先级 支持 不支持 不支持
高可用性和故障转移 支持，取决于存储，如果使用levelDB，则需要ZooKeeper服务器 支持，需要ZooKeeper服务器 支持，主从模式，无其他套件
消息跟踪 不支持 不支持 支持
配置 默认配置为低级别，用户需要优化配置参数 Kafka使用键值对（key-value）格式进行配置。这些值可以通过文件或编程方式提供。 开箱即用，用户只需注意几个配置
管理和操作工具 支持 支持，使用终端命令显示核心指标 支持丰富的web和终端命令以显示核心指标

RocketMQ 具有以下特点：

  • 能够保证严格的消息顺序
  • 提供针对消息的过滤功能
  • 提供丰富的消息拉取模式
  • 高效的订阅者水平扩展能力
  • 实时的消息订阅机制
  • 亿级消息堆积能力

缺点：

  • 社区活跃度一般
  • 没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码


Kafka 具有以下特点：

  • 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
  • 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
  • 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
  • 完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
  • 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。

缺点：

  • Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
  • 使用短轮询方式，实时性取决于轮询间隔时间；
  • 消费失败不支持重试；
  • 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；

子分类

本分类有以下2个子分类，共有2个子分类。

K

  • Kafka‎ (9个页面、​1个文件)

R

  • RabbitMQ‎ (13个页面、​1个文件)
取自“http://wiki.eijux.com/index.php?title=分类:MQ&oldid=3378”