システムを効率的に拡張:プロセス分割と Redis による高パフォーマンスのメッセージング

言葉で簡単に説明すると、サービス A とサービス B という 2 つの別々のサービスがあり、その真ん中に pubsub サービスがあるとします。

pubsub サービスが何なのかよくわからない場合は、あるサービスからのメッセージがもう一方のサービスに到達するのを支援するブローカーとして想像してください。

次に、サービス A がメッセージをパブリッシュし、pubsub を通じてサービス B がそれを処理します。プロセスが完了すると、メッセージが処理されたことを示す別のプロセスを実行します。

十分シンプルですよね?

ただし、メッセージが大きすぎる場合、pubsub サービスの制限によりメッセージが正常に公開されない場合があります。

さて、これで私が遭遇した問題の概要がわかるはずです。では、この問題をどうやって解決したのでしょうか?次のセクションでは、私のソリューションを説明します。

私の最初のアプローチ

図からわかるように、メッセージはいくつかの小さなメッセージに分割されています。分割方法とメッセージのどの部分を分割する必要があるかは、ケースやフローごとに異なる場合があります。

ただし、私の場合、メッセージには実際には項目のリストが含まれているため、項目ごとに分割できます。

アイテムが 10 個あるとします。以前は、10 項目すべてを 1 つのメッセージで公開していました。しかし、メッセージを分割した後、そのメッセージは 10 個のメッセージに変わります。

その結果、単一のプロセスがまとめて複数のプロセスになります。 1 つのパブリッシュは 10 のパブリッシュに変わり、さらにその 1 つのプロセスが 10 のプロセスに変わります。

こうして見ると、これは理想的ではないかもしれませんが、これは私が思いついた最良の解決策であり、確かに機能します。

では、分割するだけで、それだけでしょうか?

そうではありません。プロセスが完了したことをマークする最後の部分を覚えていますか?
もしそうなら、なぜその部分が私の新しい図に欠けているのか疑問に思うかもしれません。

心配しないでください。忘れていたわけではありません。次のパートでは意図的に省略しました。

問題は、メッセージを分割していくつかのプロセスに分割すると、システムはプロセス全体が実際に終了したかどうかを認識できない可能性があるということです。これも私たちが取り組まなければならない大きな問題であり、ありがたいことに、それについても解決策を見つけることができました。

仕上げプロセスの処理方法

このプロセスは以前とまったく同じに見えますが、途中に Redis が追加されています。この場合、有効な初期カウントがあることを確認する必要があります。

私の場合、リストを公開しているので、リストの長さを最初のカウンタとして簡単に設定できます。また、カウンターについては、プロセスが完了するたびに 1 ずつ減らすことができます。そうすれば、Redis カウンターを参照するだけで、すべてのプロセスが完了したかどうかを知ることができます。 0 に達した場合は、すべてのプロセスが完了したことを安全にマークできることを意味します。

まとめ

要約すると、メッセージを複数のメッセージに分割し、複数のプロセスでまとめて処理します。メッセージ プロセスを管理するために、Redis キャッシュを使用します。

上で説明した解決策は、非常に大きなメッセージの処理で問題が発生した場合に必ず解決できるわけではありません。メッセージをストリーミングするなどの他の方法もありますが、それについては別の日の話になります。

私の記事を最後まで読んでいただきありがとうございます!私の記事を楽しんでいただき、興味深いと思っていただけたこと、そして最も重要なことに、記事が役に立ったことを心から願っています。

無料でコーディングを学びましょう。 freeCodeCamp のオープンソース カリキュラムは、40,000 人以上の人々が開発者としての職に就くのに役立ちました。始めましょう