Redis を使用して、株価データを内部ネットワークのサブスクライバーに発行するシステムを作成したいと考えています。問題は、アトミックな「スナップショットを取得してからサブスクライブする」メカニズムを実装する方法を見つける必要があるため、公開するだけでは不十分だということです。私はRedisにかなり慣れていないので、私の解決策が「適切な方法」であるかどうかはわかりません。
ある時点で、各株式には最大 10 のビッドと 10 のアスクを含む注文書があります。パブリッシャーは交換用のデータを受け取り、それをサブスクライバーに公開する必要があります。
オーダー ブックの変更の発行は発行とサブスクライブを使用して簡単に行うことができますが、接続する各サブスクライバーは、株式の現在のオーダー ブックのスナップショットを取得してから、オーダー ブックの変更をサブスクライブする必要もあります。
私が理解しているように、Redis チャネルは情報を保存しないため、発行者は変更を発行するだけでなく、ハッシュ キー (またはソートされたセット。どちらがより適切かはわかりません) で完全なオーダー ブックを維持する必要もあります。
また、Redis クライアントは、最初のチャネルにサブスクライブすると、サブスクライブとサブスクライブ解除以外のコマンドを発行できないことも理解しています。
そのため、サブスクライバー アプリケーションが起動したら、最初に完全なオーダー ブックを含むキーを取得し、次にそのブックの変更をサブスクライブする必要があります。ただし、これにより競合状態が発生する可能性があります。クライアントが現在のスナップショットを含むキーを取得した後、実際に変更をサブスクライブする前にブックの順序を変更できます。
単一の接続で subscribe を使用してから get を使用することはできないため、クライアント アプリケーションには Redis サーバーへの 2 つの接続が必要です。この時点で、同じアプリケーションで複数の接続が必要な場合、おそらく適切な方法で行っていないのではないかと考え始めました。とにかく、クライアントにはサブスクライブ接続とクエリ接続があるというのが私の考えです。まず、サブスクライブ接続を使用してオーダーブックの変更をサブスクライブしますが、イベントを処理するループには入りません。その後、クエリ接続を使用して本の完全なスナップショットを取得します。最後に、イベントを処理するループに入りますが、スナップショットを取得する前に実際にサブスクライブしたため、スナップショットが取得された後に発生した変更を見逃すことはありません。
私の目標を達成するためのより良い方法はありますか?