4

私は現在、一緒に働いている会社の小さな社内ソーシャル メディア プラットフォームを書いています。大したことはありません。40,000 人以上のユーザー。基本的には Facebook や Google+ のようなものですが、機能はかなり少ないです。

このプラットフォームには、電子メール通知システム (オンライン ユーザー向けの Ajax 通知に加えて) もあります。

ここに私の問題があります-それは単にスケーリングしていません。

送信されるすべての電子メール通知を保持する mySQL テーブルがあります。そのため、誰かがグループで記事を書くとすぐに、システムは自動的にそのテーブルに行を挿入し、email_send 関数 (cronjob) がそれらのメールをユーザーに送信します (ユーザーは、即時、毎日、または毎週の通知メールから選択できます)。

これまでのところ、グループのメンバー数が少ない場合は問題ありません。

しかし、今では 5,000 人以上のメンバーを持つグループを想像してください。ユーザーがそのグループにストーリーを投稿するとすぐに、通知テーブルへの 5,000 の SQL 挿入がトリガーされます。

これをどのように解決しますか？新しいストーリー/コメント/ものをスキャンし、バックグラウンドで email_send 関数をトリガーするサーバー上のバックグラウンド ワーカーについて考えました。このスケールの方が良いでしょうか？それとも、これには標準的な方法があり、間違った方向に考えているだけですか?

正しい方向への任意のポイントは非常に高く評価されます, ありがとう、メリークリスマス:)

// マーカス。

4

2 に答える 2

3

電子メールを送信することによって通常のWeb要求/応答フローを遅くするべきではありません-単にデータをキューにダンプし、バックグラウンドジョブにその作業を引き受けさせます-あなたはすでにcronでこれを行っているように聞こえますか？

それで、速度低下の原因はインサートですか？次に、データを正規化し、メールキューテーブルにgroupIDを挿入するだけです。そのgroupIDは、Xユーザーとその電子メールアドレスを含むグループに関連付けられています。したがって、5000ではなく1つのレコードを挿入することになります。非常に迅速に、おそらく次のようなものになります...

notificationTable
rowID | emailID | groupID | status

groupTable
groupID | groupName 

userTable
userID | userName | emailAddress | groupID

さらに詳しく知りたい場合は、メッセージングシステムを導入して、単純な（高速の）メッセージを送信し、1つ以上のリスナー（1つ以上の個別のサーバー上）が1つ以上のチャネルでメッセージを待機できるようにすることができます。

于 2012-12-21T11:58:44.200 に答える
0

さて、私は私の問題に対して次の（可能な）解決策を思いつきました：

  • 私はすでにテーブル " events " を持っています:

rowID (event_id)| story_id | initiator | group_id

  • 新しいテーブル " not_notified " を作成します:

rowID | event_id

誰かが新しいストーリー/コメントを投稿するとすぐに、システムが「not_notified」テーブルに 1 行を挿入します。

数分ごとに cron ジョブが実行され (ここで速度に問題がある場合は、別の専用サーバーから実行できます)、「not_notified」テーブルを選択します。すべてのレコードセットを繰り返し処理し、各 event_id を探し、ストーリーを取得し、ユーザーが通知を受けるように通知設定を確認し、電子メール通知をユーザーに送信します。最後に、スクリプトは「not_notified」から行を削除します。

私はおそらく「not_notified」テーブルさえ必要としません-イベントテーブルの単純な「新しい」フィールドでも実行できますが、そのテーブルの何百万ものエントリをイメージしてください...

考え？

于 2012-12-21T12:58:46.997 に答える