Redis はクリックとビューを実現します

事業内容
CMS 記事ビュー (読み込まれたタイトル数)、クリック統計 (クリックされた記事数)
以下は私が設計した統計事業です。 主なテクノロジーは、データベースの負荷を軽減するための Redis、nodejs、および Redis アプリケーションのクリック キャッシュです。 、nodejs は、非同期のノンブロッキングメカニズムを通じて CMS ビジネスロジックと統計関数の区別を実現します
パラメータ cateid (カテゴリ ID)、articleid (記事 ID)、sourceip (リクエストソース IP) を渡します
1. ストレージ戦略
1 。..
.. SHANDONG 230
2. データ同期メカニズム
今私が考えるのは、Linux 計画タスクを介したデータベースへの Redis データの固定時間
3、キャッシュ データの有効期限メカニズム
Redis の有効期限
このソリューションは、データがデータベースに入力された後に期限切れのキャッシュが確実にクリアされるように、後で同期メカニズムを実行する必要があります。同期が毎日 0 時に実行されることを考慮します。 24 時間より少し長く設定する必要があります
オプション 2: データベース同期メカニズムを通じて同時にクリアします
このオプションは、同期とキャッシュのクリーニングが同時に行われ、Redis の有効期限メカニズムが放棄されます


I専門家が欠陥と最適化を指摘してくれることを願っています
上記の Redis ストレージ メカニズムは、10,000 人のオンライン ユーザーと 1,000 人の同時実行に基づくメモリ負荷に対応できますか?
同期メカニズムとキャッシュの有効期限メカニズムについて、より良い解決策はありますか? ありがとうございます

ディスカッションへの返信 (解決策)

KEY は 2014_10_30 に設定するのが最適です。

オプション 2 同時にデータベース同期メカニズムを使用して、スクリプト 1 のため毎朝 2 ～ 4 時に同期をクリアします。同期スクリプトが失敗する可能性があります。 2. データ量が多い場合、昨日の 0:00 のデータが今日の 0:00 に上書きされます

1 秒あたり 10W のリクエストとして知られる Redis は、1000 同時実行を恐れません

KEY は 2014_10_30 に設定するのが最適です。 cateid_arvicleid_t 形式

オプション 2 データベース同期メカニズムを通じて同時にクリアします スクリプトが実行されるため、毎朝 2 ～ 4 時に同期します 1. 同期スクリプトが失敗する可能性があります 2.データが大きいです 昨日の 0:00 のデータは今日の 0:00 によって上書きされます

1 秒間に 10W のリクエストを主張する Redis は、1000 件の同時実行を恐れていません

ありがとうございます

確かに同期メカニズムにより、キャッシュの有効期限とキャッシュの有効期限が切れている場合、上書きを防ぐためにキー値の日付を再度区別する必要があります
分析に基づくと、オプション 2 の方が実際より実現可能です