現在、DNS はユーザーを正しいデータセンターにルーティングしており、サーバーのラウンドロビン状況が発生しています。現在、セッション情報は Cookie に保存されていますが、サイズが大きくなりすぎたため、ブラウザからデータベースに移動したいと考えています。全員がヒットする中間ボックスを作成すると、応答時間が影響を受けるのではないかと心配しています。1 か月に 2 億以上の一意のセッションについて話しているため、セッション情報をすべてのマシンに保存することは現実的ではありません。提案、考えはありますか？
2 に答える
4
memcachedのジョブ、またはセッションデータをディスクに保存する場合は、memcacheddb
Memachedは、フリーでオープンソースの高性能分散メモリオブジェクトキャッシングシステムであり、本質的に汎用的ですが、データベースの負荷を軽減することで動的なWebアプリケーションを高速化するために使用することを目的としています。
Memcachedは、データベース呼び出し、API呼び出し、またはページレンダリングの結果からの任意のデータ（文字列、オブジェクト）の小さなチャンク用のメモリ内のKey-Valueストアです。
Memcachedはシンプルでありながら強力です。そのシンプルな設計は、迅速な展開と開発の容易さを促進し、大規模なデータキャッシュが直面する多くの問題を解決します。そのAPIは、最も一般的な言語で使用できます。
于 2010-07-21T20:06:34.663 に答える
4
ブラウザベースの Cookie の役割を理解しよう
- Cookie はブラウザ プロファイルごとに保存されます。
- 異なるコンピューターまたはブラウザーからログオンした同じユーザーは、異なるユーザーと見なされます。
- 状態 Cookie はユーザー Cookie と混合されます
クッキーを分離します。
- 現在記憶されている userId などの長期的な状態の Cookie。
- セッション状態クッキー
- ユーザークッキー
あなたのサイトがサーバー側の Cookie を考慮し始めたばかりであるということは、Cookie の分離がまだ行われていないことを意味します。ユーザー Cookie は可能な限りサーバーに保存する必要があります。これにより、ユーザーが別のコンピューターまたはブラウザーでログオンしたときに、設定とショッピング カートが保持されます。開発チームは、ショッピング カートなどの一部の Cookie を、セッション状態の Cookie にするか、ユーザー情報 Cookie にするかを決定する必要があります。
ユーザー Cookie は、ユーザーがログインする場所に関係なく、Web サイト全体でアクセスできる必要があります。開発者は、ユーザーが設定またはショッピング カートを更新したときに、同じ userId が別のサイトにログインした場合に、その変更がどの程度即時に表示されるかを決定する必要があります。位置。
つまり、分散データベース システムを実装する必要があります。マスター db サーバーがあります。20 台の Web サーバーがあり、各サーバーに独自のデータベースがあるとします。
頻繁に変更される Cookie のみをローカル データベースに保存し、あまり変更されない Cookie はマスターに残します。
Cookie がローカル データベースで更新されるたびに、更新されたフラグがマスターへの更新のためにキューに入れられます。マスターの Cookie レコードは更新されず、新しいデータが存在するロケーション番号で古いものとしてマークされるだけです。したがって、そのユーザー ID が何らかの形で 3000 マイル離れた場所で同時にアクティブ化された場合、そのセッションは古いレコードを見つけて、それらのレコードから新しい場所から独自のローカル データベースとマスター データベースにコピーする要求をトリガーし、レコードはもはやとしてマークされません。マスターデータベースで古い。
次に、最も頻繁に使用される Cookieの定期的な同期をスケジュールします。同期の頻度は毎晩にすることも、Cookie の変更の特性評価の結果に依存することもできます。
まず、プログラマーは、すべての Cookie の読み取り/書き込みをログに記録するルーチンを作成する必要があります。最初のコンポーネント分析を実行するには、1 週間分の Cookie の読み取り/書き込みアクティビティを収集する必要があります。
Cookie、ユーザーID、および変更頻度ごとに、簡単な統計的特徴付けを実行します。次に、設定に沿ってスライドして、すべてのローカル データベースにプッシュされる Cookie とマスターに保持される Cookie を決定します。決定は、ローカル データベース上の Cookie ブロックのサイズと、許可するデータベース同期の頻度との間でバランスを取ります。つまり、すべてのユーザーが同じ Cookie セットを伝播しているわけではありません。もちろん、プログラマーは通常の再キャラクタライゼーションを自動化するルーチンを作成する必要があります。ユーザーごとではなく、クラスター分析を使用してユーザーをグループ化することにより、Cookie 伝播の処理負荷を軽減したい場合があります。サイトのユーザーのグループ化が非常に明白であるため、クラスター分析を実行する必要がない場合があります。
ほとんどの Cookie が、週次更新よりも長いバケットに分類される可能性があることに驚くかもしれません。または、最悪の場合、毎日更新します。受け入れる必要がある最悪のケースは、ローカル データベースにプッシュされない Cookie フィールドの 1 時間ごとの更新です。マスター データベースから取得されるのではなく、ローカル データベースで Cookie アクセスが発生する可能性を高めたいと考えています。したがって、めったに変更されない「設定」をクリックすることをユーザーが決定した場合、「新しいサービスのプレビューを検討しましたか?」、「答えていただけませんか?」などのフリルでユーザーの注意をそらしながら、先制的にマスターから設定レコードを取得します。 「プリファレンス」Cookie がコピーされるまで、
Cookie の特徴付けは、ユーザー ID ごと、またはユーザーのクラスターごとに実行して、どの Cookie フィールドをローカル データベースにプッシュするかを決定できます。
プログラマー側の統計分析スキルはほとんど必要ないため、ユーザー ID ごとに特徴付ける方が単純です。欠点は、Web サーバーが 2 億人のユーザーごとに決定を実行する必要があることです。データベースの Cookie テーブルは次のようになります。
Cookie[id, param, value, expectedMutationInterval].
Web サーバーは、しきい値時間までに定期的にプッシュされる Cookie をユーザーごとに決定します。
SELECT param, value
WHERE expectedMutationInterval < $thresholdTime
AND id = UserId
Cookie ごとにユーザーごとの expectedMutationInterval を更新するには、Cookie の定期的な再特性化を実行する必要があります。単純な SQL クエリで、expectedMutationInterval の更新を実行できます。より複雑な分析を実行して、値 expectedMutationInterval を生成できます。
各 Cookie フィールドの変更が時間、ユーザー ID、および ipaddr ごとに記録される場合、Cookie ログ テーブルは次のようになります。
CookieLog[id, time, ipaddr, param, value].
これは、曜日/月/季節および場所/地域/ipaddr に応じて、プッシュするフィールドを自動化された再特性化ルーチンが決定するのに役立ちます。
次に、ブラウザーからユーザー情報 Cookie を削除した後でもセッション Cookie がオーバーフローしている場合は、どのセッション Cookie をブラウザーにプッシュし、どれをローカル サーバーに残すかを決定します。同じマスター ローカル データベース分析手法を使用しますが、ローカル データベースとブラウザへのプッシュのどちらを使用するかを決定するために使用されます。最も頻繁にアクセスされないセッション Cookie は、セッション属性として、またはメモリ内データベースのいずれかで、ローカル サーバーに残します。そのため、クライアントが Cookie の欠落を検出すると、サーバーに Cookie の要求を行いますが、ブラウザーで最近または頻繁に使用されていない Cookie スペースを犠牲にして、その新しい Cookie を配置できるようにします。
これらはセッション Cookie であるため、同じユーザー ID が 3000 マイル離れた場所でログオンしている場合、独自のセッション Cookie のセットを持つ必要があるため、他の場所に伝播する必要があります。
AJAX アプリの場合、クライアントはサーバーに通知せずに Cookie にアクセスするため、ブラウザーの Cookie の特徴付けは皮肉なことです。サーバーに知らせると、そもそもブラウザーに Cookie を配置するという目的が無効になる可能性があります。そのため、特徴付けのために、Cookie アクセスをサーバーに送信してログに記録するアイドル時間を選択する必要があります。
このようなレベルの粒度は、セッション ベースの Cookie であろうとユーザー ベースの Cookie であろうと、長さ (パラメーター値 + パラメーター名) が短い Cookie に適しています。
したがって、Cookie フィールドのパラメーター名と値が長い場合は、それらを量子化しようとすることがあります。ただし、量子化はもう少し複雑です。ブラウザの Cookie には多くの共通点があります。他の量子化/圧縮方法と同様に、共通点のクラスターを探し、各共通点ブロックに署名を割り当てます。次に、Cookie は量子化された署名に関して保存されます。
ブラウザベースの Cookie の量子化をどのように促進しますか? 例として GWT を使用すると、Dictionary または Map クラスを使用できます。
たとえば、Cookie "%1"="^$Kdm3i" は、LastConnectedFriend=MohammadAli@jinnah に変換される場合があります。
たとえば、Cookie を "%1" にマップできるのに、なぜ "LastConnectedFriend" として保存するのでしょうか? ユーザーがログインすると、最も頻繁にアクセスされる友人などをマップし、そのマップを GWT/AJAX 起動ページに配置してみませんか? そうすれば、セッション Cookie の長さを短くすることができます。
それで、あなたの会社は統計プログラマーを探していますか? 免責事項は、これはすぐに書かれたものであり、事実の再調整が必要になる場合があることです.
于 2010-07-21T20:17:54.437 に答える