クラスタ-metaq
2508 ワード
クラスタ
Metaはproducer,broker,consumerが分散クラスタシステムであると仮定する.
Producerはクラスタであり、複数のマシン上のproducerは同じtopicにメッセージを送信することができる.
Metaのサーバーbrokerも一般的に1つのクラスタであり、複数のbrokerが1つのクラスタを構成していくつかのtopicサービスを提供し、生産者は一定のルーティングルールに従ってクラスタ内のあるbrokerにメッセージを送信し、消費者は一定のルーティングルールに従ってあるbroker上のメッセージを引き出す.
Consumerは同じtopicを消費するために1つのクラスタに組織することもでき、このtopicへのメッセージは一定のルーティング規則に従ってconsumerクラスタ内のあるマシンに送信される.Consumerクラスタの各consumerは、同じパケット名を持つ必要があります.
Brokerクラスタ構成
Brokerクラスタの構成は簡単です.は、broker 1のプロファイル broker 2のserverを修正する.iniは、brokerIdをbroker 1とは異なる別の値に変更すれば である.はbroker 2を起動し、broker 2はbroker 1とサーバクラスタ を構成する.このプロセスでは、生産者、消費者、broker 1など、既存のサービスを再起動する必要はありません.彼らは新しいbroker 2 を自動的に感知します.
クラスタを構成するには、同じプロファイルを使用して異なる
ふかへいこう
負荷等化とfailoverは区別できませんが、生産者と消費者の負荷等化戦略をそれぞれ議論します.まずbrokerがクラスタであると仮定し,各topicには必ず複数のパーティションがある.
生産者の負荷均衡とfailover
各brokerは、1つのtopicがどれだけのパーティションを持つことができるかを構成することができますが、生産者から見れば、1つのtopicがすべてのbroker上のすべてのパーティションで1つのパーティションリストを構成して使用されます.
Producerを作成すると、クライアントはzookeeperからpublishのtopicに対応するbrokerとパーティションのリストを取得し、生産者はメッセージを送信するときにbroker上のパーティションを選択してメッセージを送信する必要があります.デフォルトのポリシーはポーリングのルーティングルールであり、1枚の図で表されます.
生産者はzkでパーティションリストを取得した後、brokerIdとpartitionの順に並べて秩序あるパーティションリストに組織し、送信時に最初から最後まで繰り返して1つのパーティションを選択してメッセージを送信する.我々のbrokerサーバのソフト・ハードウェア構成がほぼ一致していることを考慮すると、デフォルトのポーリング・ポリシーは十分です.
独自のロード・バランシング・ポリシーを実装したい場合は、前述したPartitionSelectorインタフェースを実装し、producerを作成するときに転送すればよい.
brokerが再起動や障害などでサービスできない場合、producerはzookeeperによってこの変化を感知し、失効したパーティションをリストから削除してfail overにします.故障から感知変化に遅延があるため,その瞬間に一部のメッセージ送信に失敗する可能性がある.
消費者の負荷バランス
消費者の負荷バランスは比較的複雑になる.ここでは,単一パケット内の消費者クラスタの負荷等化について議論し,異なるパケットの負荷等化は互いに干渉せず,議論する必要はない.消費者の負荷均衡はtopicのパーティション数と密接に関連しており,いくつかのシーンを考察する.まず、単一パケット内の消費者数が総パーティション数より多ければ、図のように多くの消費者が消費に参加しない
次に、パケット内の消費者数がパーティション数よりも小さい場合、一部の消費者は、メッセージの消費タスクを追加的に負担しなければならない.具体的には、例示的な図を参照すると、以下のようになる.
以上より,単一パケット内の消費者クラスタの負荷等化戦略は以下の通りである.各パーティションは、同じグループに対して1人の消費者 のみをマウントする.同じグループの消費者数がパーティション数より大きい場合、より多くの消費者は の消費に参加しない.同じグループの消費者数がパーティション数より小さい場合、一部の消費者は消費タスク を追加的に負担する必要がある.
Metaのクライアントは、消費者の負荷分散を自動的に処理し、消費者リストとパーティションリストをそれぞれソートし、上記のルールに従って合理的にマウントします.
上記から,パーティション数を合理的に設定することが重要である.パーティション数が小さすぎると、一部の消費者がアイドル状態になる可能性があります.パーティション数が大きすぎると、サーバのパフォーマンスに影響します.
ある消費者が故障したり、再起動したりする場合、他の消費者はこの変化を感知し(zookeeper watch消費者リストを通じて)、負荷均衡を再開し、すべてのパーティションに消費者が消費することを保証します.
タオバオから
Metaはproducer,broker,consumerが分散クラスタシステムであると仮定する.
Producerはクラスタであり、複数のマシン上のproducerは同じtopicにメッセージを送信することができる.
Metaのサーバーbrokerも一般的に1つのクラスタであり、複数のbrokerが1つのクラスタを構成していくつかのtopicサービスを提供し、生産者は一定のルーティングルールに従ってクラスタ内のあるbrokerにメッセージを送信し、消費者は一定のルーティングルールに従ってあるbroker上のメッセージを引き出す.
Consumerは同じtopicを消費するために1つのクラスタに組織することもでき、このtopicへのメッセージは一定のルーティング規則に従ってconsumerクラスタ内のあるマシンに送信される.Consumerクラスタの各consumerは、同じパケット名を持つ必要があります.
Brokerクラスタ構成
Brokerクラスタの構成は簡単です.
conf/server.iniを新しいbrokerにコピーし、broker 2と仮定する.クラスタを構成するには、同じプロファイルを使用して異なる
brokerIdを定義するだけでよいことがわかります.ふかへいこう
負荷等化とfailoverは区別できませんが、生産者と消費者の負荷等化戦略をそれぞれ議論します.まずbrokerがクラスタであると仮定し,各topicには必ず複数のパーティションがある.
生産者の負荷均衡とfailover
各brokerは、1つのtopicがどれだけのパーティションを持つことができるかを構成することができますが、生産者から見れば、1つのtopicがすべてのbroker上のすべてのパーティションで1つのパーティションリストを構成して使用されます.
Producerを作成すると、クライアントはzookeeperからpublishのtopicに対応するbrokerとパーティションのリストを取得し、生産者はメッセージを送信するときにbroker上のパーティションを選択してメッセージを送信する必要があります.デフォルトのポリシーはポーリングのルーティングルールであり、1枚の図で表されます.
生産者はzkでパーティションリストを取得した後、brokerIdとpartitionの順に並べて秩序あるパーティションリストに組織し、送信時に最初から最後まで繰り返して1つのパーティションを選択してメッセージを送信する.我々のbrokerサーバのソフト・ハードウェア構成がほぼ一致していることを考慮すると、デフォルトのポーリング・ポリシーは十分です.
独自のロード・バランシング・ポリシーを実装したい場合は、前述したPartitionSelectorインタフェースを実装し、producerを作成するときに転送すればよい.
brokerが再起動や障害などでサービスできない場合、producerはzookeeperによってこの変化を感知し、失効したパーティションをリストから削除してfail overにします.故障から感知変化に遅延があるため,その瞬間に一部のメッセージ送信に失敗する可能性がある.
消費者の負荷バランス
消費者の負荷バランスは比較的複雑になる.ここでは,単一パケット内の消費者クラスタの負荷等化について議論し,異なるパケットの負荷等化は互いに干渉せず,議論する必要はない.消費者の負荷均衡はtopicのパーティション数と密接に関連しており,いくつかのシーンを考察する.まず、単一パケット内の消費者数が総パーティション数より多ければ、図のように多くの消費者が消費に参加しない
次に、パケット内の消費者数がパーティション数よりも小さい場合、一部の消費者は、メッセージの消費タスクを追加的に負担しなければならない.具体的には、例示的な図を参照すると、以下のようになる.
以上より,単一パケット内の消費者クラスタの負荷等化戦略は以下の通りである.
Metaのクライアントは、消費者の負荷分散を自動的に処理し、消費者リストとパーティションリストをそれぞれソートし、上記のルールに従って合理的にマウントします.
上記から,パーティション数を合理的に設定することが重要である.パーティション数が小さすぎると、一部の消費者がアイドル状態になる可能性があります.パーティション数が大きすぎると、サーバのパフォーマンスに影響します.
ある消費者が故障したり、再起動したりする場合、他の消費者はこの変化を感知し(zookeeper watch消費者リストを通じて)、負荷均衡を再開し、すべてのパーティションに消費者が消費することを保証します.
タオバオから