“分类:MQ”的版本间差异
跳到导航
跳到搜索
无编辑摘要 |
|||
| 第29行： | 第29行： | ||
=== 不同MQ的特点对比？ === | === 不同MQ的特点对比？ === | ||
没有最好的消息中间件，只有最合适的消息中间件： | 没有最好的消息中间件，只有最合适的消息中间件： | ||
: [[File:MQ对比1.png| | : [[File:MQ对比1.png|800px]] | ||
: [[File:MQ对比2.png| | : [[File:MQ对比2.png|800px]] | ||
* 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。 | * 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。 | ||
2021年5月15日 (六) 04:06的版本
消息中间件
关于
系统间通信方式？
一种是基于远程过程调用的方式（如 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的特点对比？
没有最好的消息中间件，只有最合适的消息中间件：
- 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 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越高，发送消息响应时间变长
- 使用短轮询方式，实时性取决于轮询间隔时间；
- 消费失败不支持重试；
- 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；