サブスクリプション - 大きなコンテンツとサブスクリプションの量を処理するにはどうすればいいですか？

Question

各ユーザーのサブスクリプションの種類に応じて、ユーザーに通知を送信しています。例えば

：すべてに加入したすべてのコメント

User Cに加入して、すべてのニュース記事

User Bに加入

• User Aサイトに新しいです

私は、スクリプトを持っていますスクリプトがまだ実行されていない限り、5分ごとに実行します。

1. は、新たな「コンテンツ」（コメント、ニュース記事など）はそれぞれの結果について最後の実行
2. ので、投稿、各ユーザーのために、「コンテンツ」
3. に加入し、各ユーザーをフェッチ、通知
を送信ゲット

私が懸念しているのは、1,000の新しい「コンテンツ」があり、その50％をユーザーが購読していると、スクリプトが永遠に終了するか、サーバーがクラッシュするということです。

私が考えているのは、実行ごとに100個の新しい「コンテンツ」を選択し、ユーザーに通知することです。私はまだそれにサブスクライブすることができるユーザーの量の問題があります。

私はすべてのユーザーに到達するまで、選択したユーザーの数を100に制限できました。

これは正しいアプローチですか？これを行う簡単な方法はありますか？大規模なウェブサイトはどのようにユーザー通知を処理しますか？

Answer 1

ユーザーのバッチを処理できる（メールを送信する）ことができれば、1つのプロセス/サーバーにとって作業があまりにも多くなったように、複数の「作業」がすべて自分のバッチ。

これは、スクリプトを実行したりサーバーをクラッシュさせるのに長い時間を費やしているあなたの懸念についてはわかりません。私はそれがあなたがコードで作業するための問題だと思う。あなたが行っているコードとdbクエリのプロファイリングは必須です。

バッチのルートを行った場合、どのユーザーにどの通知を送信したかを把握する必要があります。私はあなたが各ユーザーコンテンツのペアの行を持つテーブルを保持しないことを強くお勧めしたいと思います。ユーザーに送信された最後のイベント（記事またはコメントの公開時刻）を保存するだけで、まだ送信する必要があるものを簡単に処理でき、巨大なテーブルにはなりません。

私は、コードとクエリを調査タスクとしてプロファイリングし、そのルートを通じて最も効果的な方法を解説することをお勧めします。

Answer 2

データベースがどのように設定されているかについて知らずにこれに答える方法は分かりません。正しい設定では、新しいコンテンツについて通知を受ける必要があるすべてのユーザーを提供する単一のクエリを記述することが可能になります。以下のような

何か：

SELECT u.user_email 
FROM user_table AS u 
LEFT JOIN subscription_table AS s 
ON s.user_id = u.user_id 
LEFT JOIN content_table AS c 
ON c.content_type = s.content_type 
WHERE c.add_time > LAST_RUN_TIME 

がうまくいけば、あなたは始めるべきです。