メッセージングミドルウェアとして、RocketMQは、分散システムの分野に反映され、実際に技術的な問題を解決する必要があります。まず、分散通信における分散システム、4つの部分に分割され、分散ストレージ、分散コンピューティングと分散管理は、実際には、あなたは4つのサブ・テクノロジー・スタックの下で技術の多くを見つける場合。RocketMQは、TCPに基づいている。ここで、このような、上記の選択のための分散型通信ネットワークプロトコルのようにいくつかの簡単な例は、であるAliware MQ RocketMQカーネルがゲートウェイHTTPプロトコルに基づいている間に、プロトコルは、MQTTを提供しますゲートウェイ。ネットワークプロトコルとして選択することに加えて、非常に古典的な問題を分散通信の分野に属し、I / Oモデルが存在するであろう。、最初のボスとワーカーモデルと呼ばれる4つに通常の状況下では希望I / Oモデル;、いわゆるスレッドはスレッドとイベント処理を選択するだけボスのモデルがあるので、本当のボスの内部に統一されていますスレッドコンテキストスイッチ生成オーバーヘッドを減少させる;第三のI / Oモデルは、メモリなどのいくつかの比較的重い負荷において、I / Oモデルを統合第一及び第二のことがあり、統計的理論を使用してシナリオの下で、モデル2のスイッチからのモデルは、いわゆる動的なモデルになります。第I / Oモデルは、実際にはトランスポート層のフレームワークネッティーとグリズリー・パーは、リーダー/フェローの枠組み、実際にはリーダー/フェロー、このセクションで選択したスレッドを選択する権利と呼ばれる、オープンソースの世界で使用されている、一般的ではありません労働者、およびIO処理イベントセレクタスレッドへ。分散コンピューティング、分散ストレージ領域についての話に再びオーバーチャット、それはまた、最も複雑な分散型の地域、構造化ストレージ、半構造化、非構造化ストレージを含む分野で克服する最も困難です。また、分散コンピューティングの分野では、主に、チャート計算を計算ストリーミング関連するコンテンツを含むであろう。分散管理では、分散データ管理を含む多くのサブ技術を伴うだろう、問題データの複数のコピーだけでなく、分散管理関連分野に属しているすべてのそれらの分散の一貫性、協調を伴うがあるでしょう。
プロジェクトのアイデア、技術的な詳細や今後の計画：RocketMQ共同創設者インタビュー
編集者のメモ
オープンソース環境が良くなっている年間で、大手IT企業は、いくつかの自習からオープンソースコードに回っています。2012年には、その第三世代からアリババの売上高は、研究のメッセージングミドルウェア--RocketMQを配布しました。技術的なポリッシュの数年後、アリはRocketMQベースの技術は、現在の二から一一日間の容量は1兆のメッセージを達することができると言いました。
2016年11月には、アリRocketMQには、Apache Software Foundationに寄付されます、インキュベーター・プロジェクトとなりました。アリはそれがトップレベルプロジェクトを戦うことになると述べました。オープンソースソフトウェア基盤の添加はパーティー後に観察評価し、評価を必要とするので、これはアリは、大きな一歩です。率直に言って、業界だけでなく、ステレオタイプを保ったオープンソースコードの人々の参加のために、とApache Foundationの342件のプロジェクト、まだのみ麒麟、CarbonData、イーグルとRocketMQ 4つの中国の技術主導のプロジェクトの合計インチ
2017年2月20日、RocketMQが正式バージョン4.0をリリースし、専門家は、新しいバージョンが電子ビジネス、金融セクター、データの大部分は、物事の分野におけるプログラミングモデルの両方の分野に適用されると言います。
RocketMQプロジェクト、技術的な内容の正確どのような？なぜ予備承認財団に勝ちましたか？定住財団は意味合いがどのようなものがあり、技術の円を与えることができますか？二つのプロジェクトの共同創設者のこの質問でInfoQは、次のように内容が要約され、独占インタビューを持っていました。
回答者のプロフィール
王Xiaorui、ニックネーム宣誓ケリー、アリババのメッセージミドルウェアチームのリーダーは、高可用性の富を持って、経験を構築し、信頼性の高い分散システムは、数分布とアリババは、エンジンの最適化プロジェクトをメッセージング改善二から一一回、主導しました特許フィールドタイプ。ApacheのRocketMQ共同創設者。連絡先： [email protected]
風水嘉、神フェレットニックネーム、Alibabaのミドルウェア・アーキテクト、分散型ソフトウェアアーキテクチャの富を持って、並行性の高いウェブサイトのデザイン、パフォーマンスチューニングの経験は、フィールド内の多数の特許を配布しました。オープンソースの愛好家、データの分散、大面積、注意HBaseの/ Hadoopの/スパーク/ FLINKとは、他のビッグデータ・テクノロジー・スタックに焦点を当てました。アリは現在、ミドルウェア生態出力、雲の商業化は、Apache RocketMQ共同創設者のメッセージングのための責任があります。連絡先： [email protected]
RocketMQの起源
トーキングRocketMQの明るいスポットは、私が最初に言及するアリババ・メッセージング・エンジンの進化の歴史を持っていました。アリは進化の三世代を経験した前後に、今日にエンジンをメッセージングミドルウェア。
第一世代、プッシュモードでは、データは、リレーショナルデータベースを使用して格納されます。このモードでは、メッセージは非常に低遅延特性を有し、そして分散トランザクションをサポートすることは容易です。アリ淘宝網は、特に、高頻度取引のシナリオでは、非常に広く使用されています。典型的な代表は、ナポリを通知します。
第二世代、問い合わせ独自のメッセージストアのでプルモード、。ログ処理ではカフカのスループット性能を一致させることができますが、盲目的スループット追求していなかったエンジンメッセージング、特にその取引リンクの高い信頼性要件に、アカウント淘宝網のアプリケーションのシナリオを考慮して、しかし、最初の場所で安定性と信頼性になります。長い接続プルモード、少なくないプッシュメッセージモードのリアルタイムの側面を使用しているため。典型的なMetaQ。
ベースプルモード、分散ファイルストレージに基づいて、金融部門で信頼性の高い電気・プロバイダを再試行する追加の第二世代の機能的特性に基づいて、両方のプッシュモード、高性能、低遅延のメッセージング・エンジンRocketMQ、第3世代業務の特性、および最適化の多くを行っ。2012年以降、私たちは前のデュアルコア11トレーディング・リンク検証を経験しました。今はApache財団に寄付しました。今日では、大規模および小規模なアプリケーションのRocketMQも務めた何千ものアリ・グループ、デュアル11日には、より多くの信じられないほど1000000000000件のメッセージが流れては、当社グループの中規模および大規模な単位の安定化に重要な役割を果たしました。
実際には、RocketMQを参照してくださいすることは困難ではない、電子ビジネスシーンの厳しい分野や金融セクターを満たすために、低レイテンシーのメッセージングミドルウェア彼の最高のことができ、次第に高性能に由来し、生態系全体アリババの成長を伴っています。
RocketMQの技術概要
ください図同時にアーキテクチャとRocketMQを説明、メッセージを生成するために、送信および消費プロセスは、好ましくは、図を装備することが、以下に説明するください。
我々の見解では、それが最大のイノベーションは、洗練された水平、垂直方向の拡大による高スループット、高い信頼性、尊敬の低レイテンシ要件に成長しているマスメッセージを満たすために続けています。
現在RocketMQは、主に、図に示すように、四つの部分ネームサーバ、ブローカー、プロデューサーとコンシューマーから構成されています。
すべてのクラスタは、水平スケーラビリティ、ノーシングルポイントバリアを持っています。
サービス検出およびルーティング機能を提供するネームサーバ軽量な方法は、各ネームサーバが、このような急速なスケーリング能力をサポートするための識字サービスを提供するものとして、ルーティング情報の全体量。
軽量サポートへのメッセージストアを担当するBrokerのトピック緯度キュー、スタンドアローンのキューサイズ、サポートメッセージのプッシュとプルモデルの缶のサポート数千、複数のコピーでフォールトトレラントメカニズム（2またはコピーの3つのコピー）、負荷シフトと強力に億のメッセージ蓄積能力、厳密に整然としたメッセージを確保しながら、。また、ブローカーはまた、オフサイトのディザスタリカバリ機能都市、豊富なメトリックの統計情報と警報メカニズムを提供します。これらは、従来のメッセージングシステムが一致しないことができます。
プロデューサーには、迅速な故障をサポートし、低レイテンシーを送信するためにプロデューサーブローカークラスタのロードバランシングモードで送信されたメッセージの様々なを介してユーザによって展開を配布しました。
消費者はまた、ユーザーによって展開され、ほとんどの消費者のシーンを満たすために、リアルタイムのニュースのサブスクリプション・メカニズムを提供し、サポート・クラスターにPUSHとPULL消費パターン、消費者や放送メッセージの2種類をサポートしています。
11経験豊富な二重の洗礼ヒーロー
2016二から一一の準備をすると、チームは、二つのことをやって遅いリクエストやユニファイド・ストレージエンジンの最適化に焦点を当てました。
- 最適化の遅い要求：これは主に大規模な並行性の高いシナリオ、グリッチの問題を持ち込むには、クラスタ全体でジッタを低減するために、低速の要求を解決します。これは、フォローアップのリカバリディスクケースから一ヶ月以上のビューの二から一一ポイントをチューニングを通じて、学生のチームに挑戦技術的な活動である、遅延の99.996パーセントは99.6％ながら、10msの範囲内にあります1ミリ秒未満の遅延。RocketMQの最適化は、最適化アルゴリズムの貯蔵層、JVMおよびオペレーティングシステムのチューニングに焦点を当てました。詳細については、あなたは、[1]「1000000000000ピーク時のエンジンデータを分散型メッセージング」私たちの前に書かれた電子書籍の章を参照してくださいすることができます。
- ユニファイドストレージエンジンで見てみましょう：メッセージング・エンジン・可用性、コストのための主要なソリューション。多世代のメッセージング・エンジンの共存の前提の下で、我々は包括的な移行と交換のためにメモリモジュールを通知します。
この方法では、完全に低遅延のストレージエンジンのRocketMQを受け入れるための内部Alibabaのメッセージングミドルウェア。上記正の技術的準備をもとに、16年の二から一一の間に、アリのグループ総売上高1200000000000、二から一一大きなプロモーションのほぼ倍の15年間についてのニュースがあります。ピーク期間、/ SまたはW 2000生産におけるメッセージスループットので、消費スループットメッセージ1500のほぼ順/ sのWもあります。全体の大きなプロモーションの下、社内の言葉で、滑らかな絹のような。
RocketMQ VSいくつかの他のメッセージングミドルウェア
してください、演奏練習や適用技術思想を比較して3つのシナリオRocketMQ、RabbitMQの、カフカ、ActiveMQのとZeroMQの一般的な方向？技術的なコンテストに加えて、かどうかこれらのミドルウェア、アプリケーションのビジネスケースの背後にあるコミュニティ事業者のために、それを比較しますか？
1、CSアーキテクチャではありませんか？
あなたが同様の製品間の水平方向の比較を行うために必要がある場合は、私たちの優先順位は、その名0MQとしてZeroMQ、ZeroMQを獲得し、それは、より多くの組み込みネットワークライブラリのような通信コンポーネントのトランスポート層上ではなく、伝統的な意味に焦点を当てていますMQ CSアーキテクチャ。
2、仕様/プロトコルの種類を達成するために？
次の我々は、ビューの設計思想から、RabbitMQの、ActiveMQの、カフカとRocketMQ間のコントラストの一部を見て、RabbitMQのAMQP仕様はリファレンス実装であり、AMQPは、ワイヤ層プロトコル、全抱きしめるは、それがシステムであるが、やや複雑です。現在のRabbitMQは、OpenStackのIaaSのメッセージングサービス、自明の背後にその支援のための最適なプラットフォームとなっています。
ロジックブレーズ、レッドハットの今主要な開発、中にActiveMQの最初の主要な開発者は、それがApacheのベテランニュースサービスエンジンで、JMS仕様のリファレンス実装です。それはJMS APIレベル契約であるが、それはまだ内部実装上の制約を定義しますが、が、多言語サポートの欠如。ActiveMQのは、アポロのScalaのAMQに及びそうに基づいて、次の世代として知られているアルテミスのHornetMQ進化、からを含め、多くのサブプロジェクトで、トップレベルのApacheプロジェクトにおけるエコカラフル呼ばれます。
3、シーンの種類のために？
そして、カフカはもともとログ処理を行うように設計された、真のビッグデータチャネル、高スループットの追求で、失われたメッセージがあるかもしれません。R＆Dチームはカフカにも、広くいくつかの中小企業で使用されている商用パッケージされている忠実な保留の数だったの背後にまわりもあります。
インターネットドメインと財務の健全性として生まれRocketMQは、高い信頼性、高可用性、高並行性、低レイテンシーの追求は、アリババは、私たちの不完全な統計によると、アプリケーションの何千ものアリ・グループに加えて、繁殖させたモデル裏返しから成功です国内の機関、使用中の研究・教育機関の少なくとも何百もあります。コントラストのこれらのより詳細な特性にMQ製品は、我々は公式サイト[2]の説明を参照することができます。
3つの技術力・ポイント
メッセージのシーケンス（A）
確かに、メッセージシーケンスはRocketMQが特徴セールスポイントです。現在、我々は、グローバルな安全保障秩序を行います。ここでは、話することが重要である、特定の製品のオーダーなど、大きな売り手はアカウント言う（一意の識別子であることをハッシュ）固有の識別のために、全体的な前提です。その技術は、シングルプロセス、シングルスレッドの書き込み、単一プロセス、スレッドの読み取り、ActiveMQのような独占消費者も同様の実装として、チャンネル操作の単一のインスタンスを確保するため、比較的単純な原理です。
簡単には、この実装は、実際のスループットで、いくつかの犠牲を作られていることを確認します。さらに、それはまた別の問題をもたらす - ホットスポットを。あなたは、単純なハッシュ戦略を使用している場合、このような二から一一日として、猫のビジネスメッセージの短期取引日の数十億ドルと最新RocketMQは、スタンドアローンバージョンでは、単一チャネル、あるいはホットな問題で、その結果、チャネルの内部に送られ、私たちは、注文が、この機能は年半ばにリリースされると予想されて発生したため、それによってシングルチャネルホットな問題を改善し、現在の実装が改善されます。
メッセージの重量（B）と
、（一度最大で）最大の時間の少なくとも一方（少なくとも1回）、一つだけ（正確に一度）：フィールドは、QoSメッセージが分割され、メッセージを配信した定義します。
几乎所有的MQ产品都声称自己做到了At least once。既然是至少一次，那避免不了消息重复，尤其是在分布式网络环境下，而这个缺憾归根结底也可以看做是TCP协议的一部分，如失败重传。业务上往往对消息重复又很敏感，RocketMQ目前的版本是不支持去重的，我们通常建议用户通过外置全局存储自己做判重处理。在下一代的特性规划里，我们会内置解决方案。先说下业界通用做法，像Artemis，IronMQ等，通过在服务端全局存储判重。这是一个IO敏感的操作，为服务端带来一定的负载。而RocketMQ则希望通过采取二次判重策略，有效降低服务端IO。
（三）分布式的挑战
首先明确分布式系统这个概念：分布式系统是由一系列分散自治组件通过互联网并行并发协作，从而组成的一个coherent软件系统。它具备资源共享，并行并发，可靠容错，透明开放等特性。像CAP，BASE，Paxos，事务等一起构成了分布式基础理论。
这里我们再来重温下CAP理论：CAP分别代表一致性（Consistency），可用性（Availability），分区容忍性（Partition tolerance）。一致性，Eric Brewer（CAP理论提出者）用一个服务要么被执行，要么不被执行来定义(原文：A service that is consistent operates fully or not at all)。请注意，这里的一致性是有别于数据库ACID属性中的C，数据库层面的C指的是数据的操作不能破坏数据之间的完整性约束，如外键约束。在分布式环境中，可以把C简单理解为多节点看到的是数据单一或者同一副本。可用性，意味着服务是可用的（原文：the service is available (to operate fully or not as above)）。可用性又可以细分为写可用和读可用。在分布式环境中，往往指的是系统在确定时间内可返回读写操作结果，也即读写均可用。分区容忍性，除了整个网络故障外（如光纤被掘断），其它故障（如丢包、乱序、抖动、甚至是网络分区节点 crash ）都不能导致整个系统无法正确响应（原文：No set of failures less than total network failure is allowed to cause the system to respond incorrectly）。
CAP理论可以看做是探索适合不同应用的一致性与可用性平衡问题。
- 没有分区的情况：可以同时满足C与A，以及完整的ACID事务支持。可以选择牺牲一定的C，获得更好的性能与扩展性。
- 分区的情况：选择A（集中关注分区的恢复），需要有分区开始前、进行中、恢复后的处理策略，应用合适的补偿处理机制。像RocketMQ这样的分布式消息引擎，更多的追求AP。再强的系统也一定有容量底线，足够的容量是可用性的有效前提。通常情况下，会通过降级、限流、熔断机制来保障洪峰下的可用性。具体的技术细节可以参看电子书章节[1]
另外，考虑到在金融高频交易典型场景，我们也为RocketMQ设计了CP机制，在满足分布式系统的分区容错性的前提下，牺牲系统可用性来保证数据的一致性。而技术实现上，则基于Zab一致性协议，利用分布式锁和通知机制，以此来保障多副本数据的一致性。
开源捐赠和社区运营
目前国内外有很多公司会把一些通用问题的解决方案，尤其是那些久经考验、愈久弥坚的产品开源出来，以期望在品牌宣传、人才引进方面有所建树。把RocketMQ开源出来，甚至捐赠给Apache，内部也是经过了深思熟虑，层层审批与讨论，期望能够在生态化、规范化、国际化、商业化方面深耕细作。
开源捐赠的想法实际上始于2014年。当时，我们甄选了几位Apache社区权威人士，遗憾的是反复沟通不断修改草案之后突然间失去了联系。2015年，我们有幸结识了Kylin Principal Architect蒋旭和VP Luke以及RedHat Principal Software Engineer姜宁，请教了一些Apache禁忌事项，重新活跃起来了捐赠进程。接下来，最重要的是征集champion候选人，很开心的是ActiveMQ VP Bruce爽快地接收了我们的邀请，经过前前后后接近100封邮件来往，我们终于正式开启了Apache之旅。捐赠投票是在双十一当天，我们准备充分很好地回答了评委会的犀利问题。不过，面对“中国开发者不喜欢邮件沟通”突然刁难，还要感谢社区华人的防御性声明回应。经过很多磨难，投票结果总算出来了：还不算坏10票赞同，带binding（IPMC成员的有效投票）的+1，无反对票，正式进入孵化期。孵化成功后有望成为国内首个互联网中间件在Apache上的顶级项目，成为全球继ActiveMQ，Kafka之后，分布式消息引擎家族中的重要成员。
接下来，我们想强调下知识产权这个对大多数工程师来说陌生的领域，尤其是专利权、著作权、商标权。在国外，每年因为这些问题导致的侵权官司不在少数。而我们在开源之初，对这块的选择、保护也是极其谨慎，包括开源许可协议的选择、授权方面，代码署名权等，这些都是很好的智力保护，也是我们产品的核心竞争力之一。尊重知识，尊重产权，才能构建一个和谐积极向上的开源氛围，打造真正的自主知识产权品牌产品。
在Alibaba，我们基于开源引擎的RocketMQ，为云上用户提供了商业化版本的Aliware MQ。两个产品都是由阿里中间件消息团队出品。商业版Aliware MQ 在支持 TCP 、HTTP 和MQTT 协议接入，功能方面增强了运维管控方面，生态集成的能力（包括可视化的消息轨迹、资源报表统计以及监控报警、Kafka集成等）。它在公有云上本身具备多机房部署同城高可用容灾特性，目的是满足企业级要求。
关于社区的运营，我们采取了和Apache顶级项目基本相似的策略。首先，必须立足于高质量产品本身，从版本规划开始，我们建立了里程碑讨论，Features设计，编码自测，结对Review，集成测试，Release讨论，Release公告等等一系列规范且高效的软件研发流程。其次，在社区运营层面，则有一系列与社区互动的活动，如线下meetup、workshop、ApacheCon、不定期的编程马拉松等，吸纳新的Contributor和Committer进来。
新一代RocketMQ，蓄势待发
最近，团队也在着手构建下一代RocketMQ，期望构建一套厂商无关的集线路层、API层于一体的规范，这也是第四代消息引擎最大的亮点。目前，我们联系了Twitter、Yahoo等公司相关技术负责人，共同起草完善这一规范，而RocketMQ将会是第一批率先成为参考实现的产品。我们非常期望国内的MQ厂商亦或是分布式爱好者能够参与进来，积极在国际开源社区代表国人发声呐喊。
另外，本周，团队刚刚发布了第四代引擎的第一个版本，该版本也是进入Apache社区后的首次发版。按照我们的规划，将在今年4月左右完成整个引擎的升级重组，非常欢迎大家的使用、反馈以及参与。
最后，更多信息可以移步Apache RocketMQ官网、云栖社区、中间件官方博客以及阿里巴巴电子书。
原文发表于 InfoQ
企业级互联网架构Aliware，让您的业务能力云化：https://www.aliyun.com/aliware