查看“分类:MQ”的源代码

<div align="center"><span style="color:black; font-weight:bold; font-size:150%;">消息中间件</span></div>

== 关于 ==
=== 系统间通信方式？ ===
一种是基于'''远程过程调用'''的方式（如 '''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|800px]]
: [[File:MQ对比2.png|800px]]

* 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高 用 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越高，发送消息响应时间变长
* 使用短轮询方式，实时性取决于轮询间隔时间；
* 消费失败不支持重试；
* 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；