基本的に、私が追跡したいいくつかの指標の一部は、特定のオブジェクトが当社のマーケティング プラットフォームで受け取るインプレッションの量です。たくさんのオブジェクトを表示するとしたら、オブジェクトが提供されるたびに追跡したいと思います。
すべてのオブジェクトは、単一のゲートウェイ/インターフェースを介してクライアントに返されます。したがって、ある検索条件を含むページに対するリクエストが届いたと想像すると、その検索リクエストは Solr インデックスにプロキシされます。
その後、10 個の結果が返されます。
これらの 10 の結果のそれぞれが印象として見なされます。
信じられないほど高速で正確な実装を見つけるのに苦労しています。
これを行う方法について何か提案はありますか? テクノロジーはいくつでも投入できます。現在、Gearman、PHP、Ruby、Solr、Redis、Mysql、APC、および Memcache を使用しています。
最終的には、すべてのインプレッションが最終的に mysql に永続化されるはずです。これは 1 時間ごとに行うことができます。しかし、実際の検索リクエストの読み込み時間に影響を与えることなく、インプレッションをメモリに高速に保存する方法がわかりません。
アイデア (オプション 4 と 5 を追加しただけです)
結果がクライアントに返されると、クライアントはプラットフォーム上で base64 でエンコードされた URI を要求します。これには、提供されたすべてのオブジェクトの ID が含まれています。次に、このオブジェクトが gearman に渡され、gearman がカウントを redis に保存します。1 時間に 1 回、redis がフラッシュされ、mysql 内のオブジェクトごとにカウントが増分されます。
Solr から結果が返されたら、ループして Redis に直接保存します。（速度についてはこれをベンチマークしていません）。1 時間ごとに mysql へのフラッシュを繰り返します。
Solr からアイテムが返されたら、すべての ID を 1 つのジョブで Gearman に送信します。これにより、Redis に送信されます。
新しいアイデア返される項目の最大数は約 20 であるため、返された ID の base64 ヘッダーを使用して X-Application-Objects ヘッダーを設定できます。これらの ID (ヘッダー内) は nginx によって取り除かれ、カスタム LUA nginx モジュールを使用して、ID を nginx から Redis に直接書き込むことができました。これはやり過ぎかもしれませんが。ただし、これの利点は、nginx が redis に書き込んでいる間、すぐに応答オブジェクトを返すように指示できることです。
新しいアイデアリクエストを nginx にフラッシュバックするために使用
fastcgi_finish_request()しますが、結果を Redis に挿入します。他の提案はありますか？
編集して質問に答える:
このデータの信頼性は必須ではありません。それが最良の推測である限り。インプレッションが 30% 減少するような変動は見たくありません。しかし、10% -/+ acurracy の許容範囲は許容します。