クリックトラフィックをキャプチャするために、拡張性の高いシステムを構築する必要があります。HTTPクリックリクエストがすぐに返されるように、データを非同期で処理したいと思います。クリックトラフィックは、レポートのためにデータストアに到達する必要がありますが、リアルタイムである必要はありません。ロードバランサー（おそらくAmazonのエラスティックロードバランサー）を前に、需要を満たすために必要な数のアプリサーバーを追加することで、このソリューションを拡張できるようにしたいと考えています。私はいくつかの可能性を考えました（ところで、プラットフォームはJavaです）：
クリックデータをメモリキュー（BlockingQueueなど）に書き込みます。別のスレッドがキューをドレインし、バックエンドデータストアに挿入します。このアプローチでは、キューのサイズが使用可能なメモリに制限され、ノードがクラッシュすると、キュー上のすべてのデータが失われます。キューが特定のサイズに達するとディスクにオーバーフローするBlockingQueue実装を検索しましたが、何も見つかりませんでした。
クリックデータを各ノードのファイルシステムに100MB程度のファイルで書き込みます。その後、データはバックエンドプロセスによって収集され、データストアに挿入されます。このアプローチでは、単一障害点がなく、データが失われる可能性が低くなります。たとえば、ノードでエラーが発生した場合、そのノードはロードバランサーから削除されます。バックエンドデータストアが使用できなくなった場合、再び使用可能になったときにデータファイルの転送を再開できます。データをバックエンドデータストアに取り込むには時間がかかりますが、すべてのデータがそこに到達する限り、問題はありません。
activemqやrabbitmqなどのメッセージングシステムを使用します。メッセージングシステムは、各ノードにインストールされていない限り、単一障害点を導入します。これはやり過ぎのようです。メッセージングシステムは、永続的なメッセージを提供し、トランザクションでメッセージが1回だけ消費されることを保証します。キューのコンシューマーは、データをデータストアにロードします。メッセージングシステムはバックエンドでクラスター化できますが、n-appサーバーをサーバー化する必要があり、システムの制限要因になり、httpリクエストのパフォーマンスに影響を与える可能性があります。