まず、メッセージングミドルウェア知識
1.概要
メッセージキューは、徐々に、内部の通信システムを意味する企業のコアとなっています。これは、低い結合、信頼できる配信、ブロードキャスト、トラフィック制御、最終的な一貫性と一連の機能、非同期RPCの主な手段の1つを有します。こうしたベテランのActiveMQの、RabbitMQのように、今日の主流のメッセージングミドルウェアの多くがありますが、ホットカフカ、アリババはそうでRocketMQとを開発しました。
図2に示すように、メッセージ・ミドルウェアの組成
2.1ブローカー
コア・メッセージング・サービスを提供するサーバとして、メッセージサーバ、
2.2プロデューサー
ブローカーへの生産メッセージを担当するニュースプロデューサー、事業の創始者、
2.3消費者
消費者のニュース、ビジネスの処理側は、ブローカーとビジネスロジックの処理からメッセージを取得するための責任があります
2.4トピック
テーマは、サブスクリプションモデルの統一コレクションで発表された、さまざまなプロデューサーは、放送ニュースのために、別の加入者にMQサーバで分散トピックにメッセージを送信します
2.5キュー
キュー、PTPモード、特定のキューの生産者に送信された特定のメッセージは、消費者が受け取った特定のキューに指定完了メッセージにサブスクライブ
2.6メッセージ
メッセージ本体、固定フォーマットサービスデータをカプセル化するために符号化されたデータパケットにより定義される異なる通信プロトコルに従って、メッセージの送信を達成するために
メッセージミドルウェアパターン分類3
ポイント3.1
PTPポイント：通信ベアラキューとしての使用
説明：
メッセージプロデューサ生産キューにメッセージを送信し、キューメッセージコンシューマと消費者メッセージから取ら。
メッセージが消費された後、消費者が消費されたメッセージにメッセージを消費することはできませんので、キューはもはや、保存されません。キューは、複数の消費者をサポートしていますが、メッセージのために、それだけで消費者が消費することができるだろう。
3.2パブリッシュ/サブスクライブ
パブ/サブパブリッシュ・サブスクライブ（放送）：通信キャリアなどのトピックを使用し
ます。説明
複数のメッセージを消費者（サブスクリプション）のメッセージを消費するがありながら、ニュースプロデューサー（リリース）トピックに発表されますが。そしてポイントは、さまざまな方法でポイントするために、トピックに投稿されたメッセージはすべてのサブスクライバによって消費されます。
複数の消費者が消費メッセージプロデューサの生産キューにメッセージを送信するために負荷分散を実現するためにキュー。消費者が利用できない場合ただし、メッセージは、消費者が利用可能になるまでのメッセージが保存されます、消費者を受け入れることができます。
このメッセージを取得することができ、それは1からNの加入者にありパブリッシュおよびサブスクライブ、あなたがメッセージを投稿するとき、すべてのサービスのこのトピックを購読するトピックを達成することは、メッセージのコピーを取得することができます。
メッセージングミドルウェアの4利点
4.1デカップリング
いいえ呼び出し関係との間の直接的な相互作用システムず、メッセージの送信を介して、システムは、侵襲的でないように、低い結合。
4.2システムの応答時間を改善します
例えば、ロジックの元のセット、支払いを完了するためには、完了するために、会員ポイント、物流、流通通知いくつかの論理を計算し、注文状況を修正するために関係することができる; MQアーキテクチャの設計により、緊急かつ重要なことができます（即座に対応する必要があります）ビジネスコールに方法、消費者の取扱いのためのキューに要求の少ない応答メッセージキューMQを使用します。
ビッグデータ処理アーキテクチャのためのサービスを提供するために、4.3
ビッグデータ、メッセージキュー、またリアルタイム処理アーキテクチャの統合、データ処理性能のためのサポートを提供するという文脈での統合などのメッセージが。
4.4 Java Message Serviceの--JMS
Javaのメッセージングサービス（Java Message Serviceの、JMS）アプリケーション・プログラム・インターフェースAPIは、メッセージを送信するには、2つのアプリケーション、または分散システム間のメッセージ指向ミドルウェア（MOM）にJavaプラットフォームで、非同期通信。
P2Pとパブリッシュ/サブスクライブ・メッセージング・モードでのJMS：ポイントは（ポイントツーポイント、キュー）を指すようにし、もともとJMSによって定義された（トピック、パブリッシュ/サブスクライブ） -サブスクライブ公開します。2つのモード間または問題を解決する主な違いは、消費（マルチサブスクリプション）を繰り返すことができ、メッセージ・キューに送信されます。
5 消息中间件应用场景
5.1 异步通信
有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
5.2 解耦
降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
5.3 冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
5.4 扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
5.5 过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5.6 可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
5.7 顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
5.8 缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
5.9 数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
6 消息中间件常用协议
6.1 AMQP协议
AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
优点：可靠、通用
6.2 MQTT协议
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
6.3 STOMP协议
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）
6.4 XMPP协议
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
6.5 其他基于TCP/IP自定义的协议
有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。
7 常见消息中间件MQ介绍
7.1 RocketMQ
阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：
- 能够保证严格的消息顺序
- 提供针对消息的过滤功能
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
官方提供了一些不同于kafka的对比差异：
https://rocketmq.apache.org/docs/motivation/
7.2 RabbitMQ
使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。
7.3 ActiveMQ
Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
7.4 Redis
使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
7.5 Kafka
Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：
- 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
- 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
- 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
- 完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
- 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
7.6 ZeroMQ
号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。
特性：
- 无锁的队列模型：对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。
- 批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。
- 多核下的线程绑定，无须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。
二、主要消息中间件的比较
综合选择RabbitMq
转自https://blog.csdn.net/wqc19920906/article/details/82193316