著者|キムキング
ソース| CSDNブログ、エディター| Xi Yan
出品 | CSDN（ID:CSDNnews）
分散テクノロジーの開発に伴い、MQテクノロジー製品にも爆発が見られます。現在、Apache ActiveMQ、Kafka、Pulsar、RocketMQ（ApacheとAlibabaの両方、ヘッドラインもRocketMQに基づいています）、RabbitMQ（Meituan、車の家で多く使用されています）などの一般的に使用されるあらゆる種類のMQに加えて、主要メーカーは私は自分の製品、TencentのCMQとTubeMQ、JDのJDQ、QunarのQMQ、およびDidiのDDMQ（RocketMQに基づく）を調査したので、それらの多くはオープンソースです。今年はオープンソースのTubeMQについてお話します。
TencentオープンソースTubeMQ
正式な紹介は次のとおりです。
https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_basic_introduction_cn.md
TubeMQは、2013年にTencent Big Dataによって開発された分散メッセージングミドルウェアシステム（MQ）であり、ビッグデータのコンテキストで大量のデータの高性能なストレージと送信に焦点を当てています。多くのオープンソースMQコンポーネントと比較して、7兆年近くにわたる大規模なデータの降雨の後、TubeMQは、大規模な実践（安定性+パフォーマンス）と低コストにおいて特定の利点を持っています。 、より多くの情報が照合されています。
TubeMQクラスタアーキテクチャ：
長年の進化の後、TubeMQクラスタは次の5つの部分に分かれています。
ポータル： APIやWebを含む、外部の相互作用と操作および保守操作を担当するポータルパーツ。APIはクラスター外の管理システムに接続します。Webは、APIに基づく日常の操作および保守機能のページカプセル化です。
マスター：クラスター制御の制御部分を担当します。この部分は1つ以上のマスターノードで構成され、マスターノード間のハートビートキープアライブによるマスターHA、リアルタイムのホットバックアップ切り替えが完了します（これは、TubeMQ Libを使用する場合、対応するクラスターすべてに入力する必要があります）マスターノードアドレスの理由）、マスターマスターは、クラスター全体のステータス、リソースのスケジューリング、権限チェック、メタデータクエリなどの管理を担当します。
ブローカー：実際のデータストレージを担当するストアパーツ。このパーツは、独立したブローカーノードで構成されます。各ブローカーノードは、トピックの追加、削除、変更、チェック、トピックのメッセージなど、このノードのトピックコレクションを管理します。ストレージ、消費、エージング、パーティション拡張、データ消費のオフセット消費など、トピックの数、スループット、容量などを含むクラスターの外部機能は、ブローカーノードを水平方向に拡張することで完成します。
クライアント：データの生成と消費を担当するクライアント部分。この部分はLib形式で提供されます。最も多く使用されるのはコンシューマーです。以前と比較して、コンシューマーは2つのデータプルモード、データ消費動作をサポートするようになりました。注文とフィルタリングされた消費の両方をサポートします。プル消費モードの場合、サービスは、クライアントを介した正確なオフセットのリセットをサポートして、ビジネス抽出1回の消費をサポートします。同時に、コンシューマーエンドは、新しいクラスター間スイッチフリーBidConsumerクライアントを起動しました。
Zookeeper：オフセットストレージのzk部分を担当します。関数のこの部分は、オフセットの永続ストレージのみに弱められています。モジュールは、次のマルチノードコピー機能を考慮して一時的に保持されます。
従来の分散型MQ構造と比較して、ブローカー機能は比較的重いです。
Kafkaと比較して、TubeMQのシステム機能：
ピュアJava実装言語：TubeMQはピュアJava言語で開発されています。これは、開発者がプロジェクトと問題処理にすばやく慣れるのに便利です。
マスター調整ノードの導入：Zookeeperを使用してメタデータ管理を完了し、HA保証を実装するKafkaと比較して、TubeMQシステムは自己管理メタデータ調停メカニズムを使用します。マスターノードは組み込みデータベースBDBを使用してクラスター内のメタデータを完了しますTubeMQクラスターのストレージ、更新、およびHAの積極的な機能は、TubeMQクラスターの操作管理および構成管理操作を担当し、外部インターフェイスを提供します。マスターノードを介して、TubeMQクラスターのブローカー構成設定、変更、およびクエリは、完全な自動閉ループ管理を実装し、これにより、システムメンテナンスの複雑さ。
サーバー側の消費ロードバランシング：TubeMQは、クライアント側の操作ではなく、サービス側のロードバランシングスキームを採用しています。これにより、システムの管理機能と制御機能が向上し、クライアントの実装が簡素化されます。これは、バランシングアルゴリズムのアップグレードにより便利です。
システムの行レベルのロック操作：行レベルのロックは、ブローカーメッセージの読み取りと書き込みで中間状態の同時操作に使用され、重複を回避します。
オフセット管理調整：オフセットは各ブローカーのみで管理され、ZKはデータ永続化ストレージにのみ使用されます（最初の考慮事項はZK依存関係を完全に削除することであり、その後の機能拡張を考慮して一時的に保持されます）。
メッセージ読み取りメカニズムの向上：Kafkaの順次ブロック読み取りと比較して、TubeMQはランダムメッセージ読み取りモードを採用し、同時にメッセージの遅延を減らすためにメモリキャッシュの読み取りと書き込みを増やします。SSDデバイスを搭載したマシンでは、メッセージラグを増やしますSSD消費の処理を転送して、消費が大幅に遅れている場合のスループット低下、SSDディスクの小容量、限られた点滅回数の問題を解決し、ビジネスの迅速な生産と消費のニーズを満たすことができるようにします（次の章で詳しく説明します）;
消費者の行動の管理と制御：システムの負荷が高いときに特定のサービスの電流を制限し、消費を一時停止し、データの取得頻度を動的に調整するなど、ポリシーを通じてシステムがアクセスする消費者の行動のリアルタイムかつ動的な制御をサポートします。
サービスの等級管理と制御：システムの運用と保守、ビジネス特性、およびマシンの負荷状況のさまざまなニーズに応じて、システムは運用と保守をサポートし、さまざまな消費者が消費する権限を持っているかどうか、消費遅延の等級保証、消費制限などの戦略を通じて動的に消費行動を制御します制御、およびデータプル周波数制御など。
システムのセキュリティ管理と制御：ビジネスのさまざまなデータサービスのニーズとシステムの運用と保守のセキュリティの考慮に応じて、TubeMQシステムはTLSトランスポート層暗号化チャネル、生産および消費サービスの認証と承認、および分散アクセス制御のためのアクセストークン管理を追加しますシステムのセキュリティの観点から、ビジネスおよびシステムの運用と保守のニーズを満たすため。
改善されたリソース使用率：Kafkaと比較して、TubeMQは接続多重化モードを使用して接続リソースの消費を減らします。論理パーティションの構築により、システムのファイルハンドルの占有を減らし、サーバー側のフィルタリングモードを通じてネットワーク帯域幅のリソース使用率を減らします。 Zookeeperの使用を取り除くことにより、Zookeeperの強い依存とボトルネックの制限を減らします。
クライアントの改善：ビジネス使用の利便性に基づいて、クライアントロジックを簡略化して最小の機能セットにしました。最初のメッセージに基づいて、応答メッセージに基づく受信品質統計アルゴリズムを使用して、不良ブローカーノードを自動的に削除しました大量のデータを送信する場合は、接続試行を使用してブロックの送信を回避します（詳細については、次の章を参照してください）。
この作品は基本的に他のMQの特性といくつかの特性を明らかにしています。実際、それはkafkaと比較されたと推測できます。多くの場所がkafkaに参加して改善し、多くの思考と新しい管理機能を生み出しました。実装。
TubeMQクライアントの進化：
TubeMQと最も接触しているビジネスは消費者側です。ビジネスの特性にどのように適応し、ビジネスの使用を容易にするか？この分野でさらに改善を行いました。
データプルモードはプッシュとプルをサポートしています：
プッシュクライアント：TubeMQの最初のコンシューマーバージョンは、プッシュモードでの消費のみを提供します。このモードは、データをより速く消費し、サーバーへの負荷を軽減できますが、問題も引き起こします。ビジネスを使用している場合、プル頻度は制御できません。データバックログを作成するのは簡単であり、データ処理を行うことはできません。
消費の一時停止/継続によるプッシュクライアント：プッシュプルアクションを制御できるかどうかに関するビジネスフィードバックを受け取った後、resumeConsume（）/ pauseConsume（）関数ペアを追加して、ビジネスがウォーターライン制御メカニズムをシミュレートしてステータスを比較できるようにしました使用中の場合、pauseConsume（）関数を呼び出して、Libバックグラウンドデータのプルを停止します。状態が復元されたら、resumeConsume（）を呼び出して、Libバックグラウンドにデータのプルを続行するよう通知します。
プルクライアント：後のバージョンでプルクライアントを追加しました。このクライアントはプッシュクライアントとは異なります。メッセージをアクティブにプルし、データ処理結果の成功を確認するのは、Libではなくビジネスです。データ処理の主導権はビジネスに委ねられています。この処理の後、サーバー側のプレッシャーは増加しますが、ビジネス消費中のバックログは大幅に軽減されます。
データ消費の動作は順序とフィルター処理された消費をサポートします。TubeMQの設計の最初に、さまざまなビジネスがさまざまなトピックを使用することを検討しました。実際の運用では、多くのビジネスが実際にプロキシモードを介してデータを報告し、データはトピックの下のファイルIDまたはテーブルを通過することがわかりました。 ID属性で区別するには、ビジネスは独自のデータを使用するために、トピックの下のすべてのデータを使用する必要があります。tidフィールドで指定された属性のフィルタリング消費モードをサポートし、サーバーにデータフィルタリングを配置して、クライアントのトラフィックとデータ処理の負荷を軽減します。
ビジネスの1回限りの消費をサポート：ビジネスがデータを処理するときに正確なファイルを戻す必要性を解決するために、クライアントバージョンはクライアントを介して正確なオフセットをリセットする機能を提供します。サービスがシステムを再起動すると、クライアントのみがコールバックを提供する必要があります消費のコンテキストでは、TubeMQは指定された正確な場所に従って消費を続けることができます。この機能は現在、Flinkなどのリアルタイムコンピューティングフレームワークで使用されており、Flinkを使用して、チェックポイントメカニズムに基づいて1回限りのデータ処理を実行します。
プッシュとプルは、メッセージ処理の2つの最も基本的なモードです。プッシュはサーバー処理の方が簡単です。プッシュされるかどうかは関係ありません。ブローカーは軽くなりますが、単位時間あたりにプッシュしすぎて、コンシューマー側にバックログが発生し、クライアント側のシステムに負荷がかかる可能性があります。プルとは、いつでもデータをフェッチするようになったときに、ブローカーがその状態を維持してバックログを生成する必要があり、再試行戦略なども処理する必要があることを意味します。オフセットを使用すると、いつでもメッセージをトレースできることを意味しますが、これにより重複が発生する可能性があります。組み込みの重複排除がない場合は、抽出は1回ではなく、少なくとも1回はメッセージが繰り返されます。
他のいくつかのMQ
DidiのDDMQ：
https://github.com/didi/DDMQ/blob/master/README_CN.md
QunarのQMQ：
https://github.com/qunarcorp/qmq
興味深い点
TubeMQと、kafka、rocketmq、pulsarなどの主流のMQアーキテクチャの違いは何ですか？
公式見解は次のとおりです。
Kafkaは順次書き込み+順次ブロック読み取りモードで実装されます。単一インスタンスのパフォーマンスデータは非常に強力ですが、インスタンスの数が増えると、パフォーマンスは不安定な低下を示します。TubeMQは最大でも順次書き込み+ランダム読み取りモードを使用します制限の下でも、システムは1Gを超える長期の安定した流入を達成でき、同時にサーバー側のフィルタリングと組み合わせて、フィルタリングの消費は非常にスムーズです。
個人的にはこれについて予約があります。多数のトピックはKafkaの設計原則に適していません（通常、単一のクラスター内のトピックの数は100未満にすることをお勧めします。小さなトピックが多すぎると、ランダムな読み取りと書き込みが発生しますが、それらをマージして、メッセージを区別してルーティングすることができます）、同時に、SSDディスクに変更すると、数千のトピックの問題でスループットと遅延も改善されます。また、kafkaのレイテンシは上記のドキュメントで比較した250ミリ秒とは異なり、実際には10〜40ミリ秒使用します。
TubeMQを見てみると、全体的なデザインはパルサーに少し似ていますが、これは主にブローカーとストレージが分離されているためです;メッセージ処理モードはActiveMQに少し近いです。
いくつかの興味深い場所：
1. TubeMQは複数のコピーをサポートしていません。この場合、極端な場合でも単一のマシンでデータが失われる可能性がありますが、複数のコピーがさまざまな分散メッセージキューの現在の標準構成です（Tencent Cloudの商用バージョンCMQをご覧ください。 。）
2.サーバー側の消費負荷分散。これは以前のバージョンのkafkaの場合であり、多くの問題があります。
3.メッセージはランダムに読み取られるため、メモリキャッシュを追加し、SSDに依存する必要があります。これは非常に奇妙です。同時実行のためにロックを追加するのは非常に複雑です。ActiveMQはメモリの処理が複雑すぎて大量になり、だれにとっても良くないためです
4.プッシュとプルを同時にサポートすることも非常に興味深いことです。これは最初のプッシュと何らかの関係があります。プッシュをサポートする場合、サーバーは確実に状態を持つ必要があります。
5.サーバー側でのメッセージフィルタリングのサポート現在、一般的なMQはクライアント側のフィルタリングですが、同じことが当てはまります。
MQはこれまでに、ActiveMQ、Kafka / RocketMQ、およびPulsarに代表される3世代を経験していることを発見しました。傾向の観点から、それはますます分散され、クラウドネイティブをサポートする傾向があり、ブローカーはますます増えています薄くて軽い。
つまり、このソリューションは従来のMQと現在のMQの特性の一部を統合しているように見えますが、実装は非常に重いです。
ヒントもあります。TubeMQのコンポーネント名は少し混乱します。マスターと呼ばれるものは実際にはブローカーです。ブローカーと呼ばれるものは実際にはストレージです（book in pulsar）。
：）
元のリンク：
https://blog.csdn.net/KimmKing/article/details/103133789
【終わり】
今日のメリット
ルーチーに会う
また、「100万人がAIを学ぶ」の重要な部分として、2020 AIProConデベロッパー1万会議が7月3日から4日にオンラインでライブ放送され、開発者はAIの最先端テクノロジーをワンストップで学ぶことができます研究、コアテクノロジーとアプリケーション、およびエンタープライズケースの実務経験。また、オンラインでエキサイティングで多様な開発サロンやプログラミングプロジェクトに参加することもできます。将来を見据えた一連のアクティビティとオンラインライブブロードキャストインタラクションに参加することで、何万人もの開発者と通信できるだけでなく、ライブブロードキャストの限定ギフトを獲得したり、テクノロジーの巨人に参加したりすることもできます。
チケットはビッグショー限定です！本日から、クリックして元の登録「2020 AI開発者1万会議」を読み、クーポンコード「AIP211」を使用して、299元相当の無料オンライン会議チケットを入手できます。100枚限定、先着順！是非、指を使って無料でメンバーシップを取得してください！
クリックして元のテキストを読み、会議の公式Webサイトに直接アクセスします。
よりエキサイティングな推奨事項
☞ワンストップキラーAI開発プラットフォームがここにあります！散在するモデリングツールの切り替えに別れを告げる
☞ 会社の仮想マシンはまだアイドル状態ですか？JenkinsとKubernetesに基づく継続的インテグレーションテストの実践について学んでください。
☞Web1.0からWeb3.0へ：ここ数年のインターネットの発展と今後の方向性の詳細な分析
あなたが注文するすべての「監視」、私はそれを真剣に受け止めます
