メッセージミドルウェアとは何ですか
メッセージ（メッセージ）アプリケーション間のデータ転送を指します。メッセージは、このようなテキスト文字列を含むように、非常に単純なことができ、 JSONなどは、もちろん、また、このような埋め込みオブジェクトなど、非常に複雑になります。
ミドルウェアメッセージキュー（ Message Queueのミドルウェア、MQと呼ぶ効率的で信頼性の高いデータ交換プラットフォームに依存しないメッセージパッシングの使用であり、分散システム統合のためのデータ通信をベース）。メッセージングモデルをメッセージ・キューイングを提供することによって、それは、分散環境内のプロセス間の通信を拡張することができます。
現在、主流があり、多くのオープンソース・メッセージング・ミドルウェアがあるのRabbitMQは、カフカが住んでいた、 ActiveMQの、RocketMQなど
分類メッセージングミドルウェア
プッシュメッセージ・モデル（PUSH）
メッセージプロデューサは、メッセージにメッセージを送信するサービス、メッセージ配信サービスとなりますにメッセージをプッシュメッセージの消費者。
プル・メッセージ・モデル（PULL）
消費者は、メッセージングミドルウェアの生産者からのメッセージが引く、メッセージサービス要求メッセージを要求し、このメッセージを。
両者の差：
モデル |
押す |
引く |
サーバー |
メッセージストレージ 処理要求を 保存するためにプッシュトラックを 保存申し込み関係 消費者のロードバランシング 集中式 |
メッセージストレージ 処理要求を 分散 |
クライアント |
応答処理要求を |
処理応答と要求を 保存プルなプルとして、状態を位置オフセットオフセット 異常のスクラッチの下のメッセージ |
リアルタイム |
より良い、データを受信した後、クライアントにすぐに送信することができます |
応じて、プル間隔 |
消費者の失敗 |
消費者の障害が発生した場合、サービスの終了メッセージの蓄積、繰り返しプッシュ-consuming リソース 保存圧力軌道の多くをプッシュします |
消費者のサーバの障害なしに影響を与えます |
他の |
メッセージは、消費者の数が増加するとき、多様化プッシュ機構を達成するために、より多くの制御のためにプッシュしているの時間は、押し圧力が得られ、処理能力に、大きなパフォーマンスの天井を消費者の違いをの蓄積メッセージ |
する必要があり、クライアント側にメッセージを実装するフィルタリング、資源の無駄 必要と異なるクライアント間の調整を、負荷分散を行います |
メッセージングミドルウェア・アプリケーションのシナリオ
リットルの回収可能性
そのような部屋の間のデータレプリケーションなど
L個の非同期通信
ユーザー登録したメールやSMS
リットルのトラフィッククリッピング
このような大きなプロモーションのスパイク活動など
別の圧力試験は、パフォーマンスのために使用することができます
リットル確保するため
例えば、決済システムでは、処理順序が重要です
リットルのデカップリング
例えば、単一ユーザシステムの下で電力会社は、注文システムは、在庫システムに通知する必要があります。、失敗したために生じた、注文システムに障害が発生した場合、その後、在庫システムが失敗するメッセージング・ミドルウェアを使用し、また結合の高度が有する;伝統的なアプローチは、システムコールインターフェース在庫システムを注文する注文入力システムと在庫システムデカップリング用途なるように、個別に設計を分離することができます。
リットルのログ収集
計算 PV、ユーザーの行動分析
RocketMQプロフィール
阿里的消息中间有很长的历史，从2007年的notify到2010年的Napoli，2011年升级后改为MetaQ，然后到2012年开始做RocketMQ，RocketMQ使用Java语言开发，于2016年开源。第一代的Notify主要使用了推模型，解决了事务消息；第二代的MetaQ主要使用了拉模型，解决了顺序消息和海量堆积的问题。RocketMQ基于长轮询的拉取方式，兼有两者的优点。
目前RocketMQ已经成为Apache顶级项目。在阿里内部，RocketMQ很好地服务了集团大大小小上千个应用，在每年的双11当天，有万亿级消息通过RocketMQ流转（在2017年双11当天，RocketMQ流转的线上消息达到了万亿级，峰值TPS达到5600万），在阿里大中台上也发挥了一定的作用。
RocketMQ的特点
l是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点
lProducer、Consumer、队列都可以分布式
l能够保证严格的消息顺序
l提供丰富的消息拉取模式
l高效的订阅者水平扩展能力
l实时的消息订阅机制
l亿级消息堆积能力
l较少的依赖
RocketMQ物理部署结构
如上图所示， RocketMQ的部署结构有以下特点：
lName Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
lBroker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
lProducer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
lConsumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
RocketMQ逻辑部署结构
如上图所示，RocketMQ的逻辑部署结构有Producer和Consumer两个特点。
Producer Group
用来表示一个发送消息应用，一个Producer Group下包含多个Producer实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个Producer对象。一个Producer Group可以发送多个Topic消息，Producer Group作用如下：
1. 标识一类Producer
2. 可以通过运维工具查询这个发送消息应用下有多个Producer实例
3. 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态。
Consumer Group
用来表示一个消费消息应用，一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象。一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。
常用RocketMQ集群模式
n单master模式
也就是只有一个master节点，称不上是集群，一旦这个master节点宕机，那么整个服务就不可用，适合个人学习使用。
n多Master模式
多个master节点组成集群，单个master节点宕机或者重启对应用没有影响。
【优点】所有模式中性能最高
【缺点】单个master节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
注意：使用同步刷盘可以保证消息不丢失，同时Topic相对应的queue应该分布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该topic的应用造成影响。
n多Master多slave异步复制模式
在多master模式的基础上，每个master节点都有至少一个对应的slave。master
节点可读可写，但是slave只能读不能写，类似于mysql的主备模式。
【优点】在master宕机时，消费者可以从slave读取消息，消息的实时性不会受影响，性能几乎和多master一样。
【缺点】使用异步复制的同步方式有可能会有消息丢失的问题。
n多Master多Slave同步复制双写模式
同多 master多slave异步复制模式类似，区别在于master和slave之间的数据同步方式。
【优点】同步双写的同步模式能保证数据不丢失。
【缺点】发送单个消息RT会略长，性能相比异步复制低10%左右。
【刷盘策略】同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
【同步方式】同步双写和异步复制（指的一组master和slave之间数据的同步）
注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低
集群模式总结
单Master无Slave（脆弱）
单master多Slave（单点故障就瘫痪，开源版本无主备切换功能）
多Master无Slave（无单点故障，prod环境常用）
多Master和Slave（无单点故障）