web-dev-qa-db-ja.com

デザインパターン：通知システム

私はソーシャルネットワーキングの機能を使用するWebサイト（たとえばFacebookなど）に取り組んでいます。

「Xがあなたを友達に追加しました」、「Yがあなたをパーティーに招待します」、「Zが最新のクイズに答えました」などの通知システムを実装したいのですが、どうすればよいかわかりません。 。

私は最善の解決策は何だろうか：

  • 解決策1、別名「ロギング」。

専用テーブル「通知」。通知が発生するたびに、このテーブルに行を追加します（友達の追加、クイズの回答など）。テーブル「通知」には、テーブルに追加される通知の種類に応じて、さまざまな情報を含むフィールドがあります。

良い：コーディングが簡単で、通知機能と「通常の」機能を分離し、リソースをあまり消費しません。表を読む必要がある場合に消費します。

悪い：通知テーブルはおそらく非常に大きくなります（テーブルに1日あたり1万行を追加すると思います）、「重複した」情報：通知テーブルの情報は、日付を使用して他のすべてのテーブルで見つけることができます/ list/whatever比較。

  • 解決策2、別名「どこでも見る」。

通知リストを表示したり、新しい通知の数を表示したりする必要があるたびに、関係するすべてのテーブルを調べ、日付などを比較して、ユーザーが最後に通知を確認してから何か新しいことが起こったかどうかを確認します。

良い：ソリューション1と比較してテーブルが大きすぎず、情報の「冗長性」がありません。

悪い：ユーザー数（〜1k +）のせいで不安です。リソース/時間がかかり、コーディング/保守が少し難しいため、サーバーが爆発します。

あなたがより良いと思うこととその理由を教えてください、または私が想像していなかった解決策がありますか？

ありがとう=）

編集：私が本当に基本的なDBデザインを使用しているとしましょう：ユーザーには友達がいて、クイズをすることができます。

ユーザーリスト、クイズリスト、

1つのテーブルクイズ<->ユーザー関係、

友情のための1つのテーブルユーザー<->ユーザー。

ユーザーが自分のプロファイルにアクセスするたびに、新しいクイズ<->ユーザー関係、新しいユーザー<->ユーザー関係など、何が起こったかを確認できます。そのような通知をどのように設計しますか？

design-patternsdatabase-design
39
Clement Herreman

システムキューを作成します。このキューに追加される各メッセージには、「コンシューマー」とコンテンツのリストがあります。メインメッセージポンプは各メッセージを処理し、すべてのコンシューマーにメッセージを送信します。

2人が友達になったとしましょう。 AがBと友達であり、コンシューマーがAとBの両方であるというメッセージをメインシステムキューに追加します。メッセージ「pump」（プロセッサ）がこのメッセージを見ると、AのキューとBのキューに追加されます。これで、ユーザーAとユーザーBは、友達であるという新しいメッセージを受け取りました。次に、各ユーザーはメッセージプロセッサを持っているため、「私は[誰か]と友達です」というメッセージが表示されると、Aの友達に表示される「壁」に「AはBと友達です」という新しいエントリを追加するように処理されます。 "など.

これは非常に単純ですが、メッセージキューをこれに使用する方法を示していることを願っています（Windows UIフレームワークとして非常によく似たシステムが使用されています）。そのため、既存の例があり、使用できる同期されたメッセージキューパターンがたくさんあります。

残りは設計するのはあなた次第です。

21
AlexC

本当にこれはどうやって車を設計するのですか？タイプの質問カテゴリに分類されます...

実装は、将来の設計、実装先、および実装する環境によって異なります。Twitter風の実装、SANに裏打ちされたXMLシステム、リレーショナルデータベース、Hadoopなどを選択できます。

Webテクノロジー、経験、試行錯誤に関する十分な知識は、機能を確実に設計できる唯一の方法であり、それが正しい方法です。

あなたのパフォーマンスのニーズは何ですか？トラフィックレベル？ユーザー要件？後で配布しますか（たとえば、Webhookを介して）。

あなたの質問はより具体的にする必要があります。

私個人的に列挙型のように機能する「notification-types」のテーブルがあります...次に、通知とユーザーの関係を処理するuser <>通知テーブルがあります。

いくつかの適切なコーディングを使用すると、user <>通知テーブルを多くのサーバーに接続し、useridなどをキー入力して、ローカルキャッシュ/参照用にこれらの各ノードにtypesテーブルを複製できます。そんな感じ。

15
Aiden Bell

AWSやAzureなどのサービスは、通知フレームワークを提供しています。これらのいずれかを使用する場合は、テーブル構造について心配する必要がない場合があります。必要なのは、アプリケーションのさまざまなポイントから通知をトリガーすることだけです。

たとえば、ユーザーが別のユーザーの何かを気に入った場合、アプリケーションは送信イベントをトリガーできます（1回のAPI呼び出しで数千人のユーザーに送信できます）。 APIはレコードを保存し、宛先ユーザーに転送します。

これは私たちにとってうまく機能しています。

これが同様の解決策を探している他の人に役立つことを願っています。

0
Rahatur

プレーン通知を使用することをお勧めします。通知タイプなどはありません。

通知
-id
-メッセージ
-href（ユーザーが通知をクリックしたときに移動するリンク）
-receiverUser
-日付

使用例：John（34）はMary（47）の写真が気に入りました。 （メアリーに通知を送信しています）

INSERT INTO Notifications(message,href,receiverUser, date) VALUES ('John liked your photo', 'link of the photo', 47, 01.11.2014)
0
Salih Erikci

私がしたことは、以下のデータを保存するための専用サービスを提供することでした：

  • レシピnt_id
  • アクターID
  • html_msg
  • meta_data
  • if_seen
  • タイムスタンプ

また、ユーザーがオンラインの場合、UIへのソケットプッシュ

0
Lubdhak