0

これは非常に一般的な問題のようですが、まだ答えを見つけることができませんでした。パブリッシュ/サブスクライブ インフラストラクチャが配置されており、ソリューションのコンポーネントの 1 つがトピックに関するメッセージを受信したときにアクションを実行する必要があるとします (アクションはメッセージごとに 1 回だけ実行する必要があります)。また、コンポーネントの可用性が高く、負荷分散のためのアクティブ/アクティブ セマンティックを備えていることも重要です。

P2P メッセージング パターンを使用すると、同じキューをリッスンするコンシューマーの複数のインスタンスを実行することで、これを非常に簡単に実現できます。ただし、pub/sub では、consumer の各インスタンスが独自のメッセージのコピーを受け取るため、同じアクションが複数回実行される可能性があります。

私が考えているアプローチは、アクティブ/パッシブ モードで実行し、メッセージをキューに転送することで pub/sub を P2P に変換する別のコンポーネントを用意することです (別のブローカーまたは Redis のようなものでもかまいません)。トランスレータの 2 つのインスタンスの間には、何らかの理由でアクティブ インスタンスが切断されるとすぐに、パッシブ インスタンスがトピックにサブスクライブできるようにするハートビート メッセージがあります。

もう 1 つのオプションは、アクティブなすべてのインスタンス間でストレージを共有することです。1 つのインスタンスがメッセージの処理を開始するとすぐに、ストレージ内でこれが示されるため、他のインスタンスはメッセージの処理を中止します。これにより、多くの競合の問題が発生し、アクティブ/アクティブ構成の利点がまったくなくなるのではないかと心配しています。

他のアプローチに関する提案、またはリストしたものに対する改良点を探しています。

4

1 に答える 1

1

プロデューサー (pub/sub) からどのような保証があるかは少し不明です。永続的なサブスクリプションをサポートできますか?

可用性の要件については、最初のソリューションがおそらくより実現可能です。リーダー選挙プロトコルの実装は、解決するのが非常に難しい問題です。そのためには、Zookeeper などの既存のソリューションを使用することをお勧めします。どの方法を選択しても、リーダーの選出には少なくとも 3 人のメンバーが必要です。たとえば、3 つの Zookeeper ノード。

データベース ロック オプションはレイテンシの原因となり、可用性の要件のためにクラスターをセットアップする必要があります。

于 2013-06-13T00:51:49.717 に答える