Java アプリケーションの JSON メッセージの一時ストレージとして単純な永続バッファを探しています。メモリ使用量は比較的一定で、バッファ内のメッセージ数には依存しません。過去のある時点からのメッセージを再生できると便利です。古いメッセージの削除は効率的です。1 時間あたり 100 万メッセージを処理できる必要があります。
現在、私のアプリケーションは、リモートの RabbitMQ ブローカーにメッセージを送信するローカルの RabbitMQ ブローカーを使用しています。リモート ブローカがダウンしているか、メッセージを受け入れていない場合、ローカルの RabbitMQ ブローカのメモリ使用量がキューの長さとともに増加し、最終的にメッセージの受け入れを停止します。これを、ローカル ディスク ベースのバッファと、リモートの RabbitMQ ブローカにメッセージをコピーするスレッドに交換したいと考えています。
誰にもアイデアはありますか？私は Kafka を見てきましたが、私のユースケースではやり過ぎのようです。MongoDB も可能ですが、メモリ使用量が心配です。
メモリ使用量は、どのシステムでも常に問題になります。私は本番環境で MongoDB を使用していますが、同様のソリューション (CouchDB、CouchBase、redis.io) と比較すると、MongoDB はメモリ管理と実装の容易さにおいて非常に優れています。しかし、Riak をこれ以上詳細にテストする機会がなかったことを認めなければなりません。
4 つのインデックス フィールドを持つ 5.000.000 のユーザー レコードと、メッセージング サービスを背後で使用する REST/Web サービス API の背後にあるすべてのユーザー セッションを保存しています。
私のメッセージング サービスは、同じサーバー上の別の db インスタンスを使用しています。ユーザー レコードには少なくとも 20 のフィールドがあり、セッション レコードには 5 つのフィールドしかありません。私のubuntuサーバーは、負荷の高いプロセスでも10 GBを超えるRAMを使用したことはありません.
これが理解に役立つことを願っています。
ps: すべては、データ モデルとインフラストラクチャの実装方法に依存します。
よろしく、
編集：
これは、メッセージングに MongoDB を使用することに関する優れたスライドショーだと思います。
また、 MongoDB とメッセージングに関するすばらしい記事もあります。
テスト コードを使用して、ソリューションの結果が適切であることを確認できます。テストした場合は、結果を共有することを忘れないでください。