Javaサーブレットブラウザプッシュ通知のアーキテクチャ

Question

Google Cloud MessagingとFirefox Push Notification Systemを介してブラウザプッシュ通知の送信を実装しています。このためには、GCMとFPNSへのHTTP投稿リクエストを作成する必要があります。

GCM/FPNSにHTTPリクエストを行うには、ユーザー登録IDが必要です。 JavaScriptを使用して、登録IDを収集し、それをCassandraに保管しています。各レコードには、ユーザー登録情報（登録IDとブラウザー・タイプ）が入っています。

HTTPリクエストをGCM/FPNSに送信すると、ブラウザの種類に基づいてGCM/FPNSにリクエストとともに登録IDを送信する必要があります（ユーザー登録IDがChromeに属している場合は、たとえば、10,000レコードがある場合、FPNS/GCMに対して約10,000件の要求を行う必要があります。

GCM/FPNSがユーザー登録IDを受信すると、ブラウザーにプッシュ通知が送信されます。ブラウザでは、通知イベントを処理するJavaScriptコード（Service Worker）があります。

上記の要件では、同期サーブレットのアーキテクチャでは十分ではありません。 10,000レコードを処理するため、マルチスレッドを使用していても10〜15分かかることがあります。 Tomcatのメモリリークやメモリ不足の例外が発生する可能性があります。

私がオンラインで検索していたとき、人々は非同期サーブレットアーキテクチャを提案しています。通知を送信するクライアントからの要求を受けたら、すぐに応答します（200 Ok Added to queueなど）。また、この要求をMessage Queue（JMS）に追加する必要があります。 JMSでは、マルチスレッド化を使用して非同期HTTP要求を行います。

これを行う正しい方法が見つかりません。この機能を実装する方法を提案できますか（アーキテクチャ設計と制御フロー）？

Answer 1

PubNubのように変更するのが短すぎると、私はワーカーキューを作成します。これは、JMSまたは共用キュー（プロデューサ/コンシューマの検索）だけで実行できます。私の意見では、JMSはクラスタ内で配布するのが一層難しくなりますが、最も簡単です。

基本的には、メッセージを受け取り、キューに入れ、200を返す同期サーブレットを持つことができます。キューにメッセージを配置すると、せいぜい数ミリ秒のブロックが最小限に抑えられます。

このように、キューの消費側では、多くの要求を処理する必要があります。システムのレイテンシ要件に応じて、スレッドをスレッド化またはオフロードする必要があります。メッセージを送信する必要があるかどうかは、実際どのくらい速いかによって異なります。

アーキテクチャがまったく異なる場合は、「クラウドのキュー」と考えることができます。私はこのようなもののためにAmazon SQSを使用しました。あなたはサーブレットを持っていなくても、メッセージはSQSにまっすぐに行き、それ以外のものはそれをプルして処理します。

参考までに、AmazonやPubNubでは動作しません。