1

Python で単純な分散データベースを設計しています。で通信層を実装することを検討していZeroRPCます。キー ルックアップは、req/repパターンを使用する DHT プロトコルによって実装されます。ただし、キーの値によって分散ルックアップを行う機能も必要です。たとえば、特定の値を持つキーをリクエストした場合、すべてのサーバーがローカル ストレージでルックアップを行い、結果をリクエスタに返すようにします。これをpub/subで実装する可能性を考えています。次のようなものです。

    #node.py
    import zerorpc
    class Node:
        def query(param):
            #lookup code
            return result # could be None or [], etc.

    sub = zerorpc.Subscriber(Node())
    sub.connect('tcp://127.0.0.1:9999')
    sub.run()


    #requester.py
    import zerorpc

    pub = zerorpc.Publisher()
    pub.bind('tcp://127.0.0.1:9999')

    result = pub.query('foo_query') # None
    print result # None

問題は、呼び出しの結果を取得できるかどうかです。取得できるpub.query()場合は、その結果を一連のサブスクライバー ノードから集約できますか。

PS間違った方向に目を向けている可能性があります。他のコミュニケーション手法を使用する必要がありますか?

4

1 に答える 1

1

Publisher->Subscriber パターンは、一方通行の通信パターンです。管理されていない作業項目の分散を実装するには良い方法ですが、双方向通信や作業の分散 (負荷分散など) をより細かく制御したい場合は、別の通信チャネルが必要になります。

あなたがやろうとしていることについて私が持っている情報に基づいて、2 つの高レベルの解決策を利用できます。

単一のゲートウェイの背後にあるサーバー ノードをブラックボックス化する

リクエスト/リプライ ブローカー パターン

「リクエスト/リプライ ブローカーを使用すると、クライアント/サーバー アーキテクチャのスケーリングが容易になります。これは、クライアントがワーカーを認識せず、ワーカーがクライアントを認識しないためです。唯一の静的ノードは、中間のブローカーです。」

ここに画像の説明を入力

このパターンの詳細については、こちらの ZMQ ガイドのコード例を参照してください。

シンプルな REQ<->REP で独自のマルチキャストを実装する

典型的なクライアント <-> サーバー モデル (REQ<-> REP) を接続に使用し、独自のコードでマルチキャストを実装します。

アプリケーションに最適なソリューションが必要であることがわかっているため、どちらのソリューションが最適かは言えません。これらは一般的な 2 つのソリューションにすぎません。ZMQ を実装するには多くの方法があり、ほぼどのような方法でも実装できます。多くの場合、最も重要なことは、高レベルで優れたパイプラインを設計し、ZMQ に戻って難しい作業を行うことです。

于 2013-11-16T11:56:53.997 に答える