Схема проектирования: система уведомлений

Я работаю над сайтом, который будет использовать функции социальных сетей (например, Facebook).

Я хотел бы внедрить систему уведомлений, которая показывает такие вещи, как "X добавил вас в друзья", "Y пригласил вас на вечеринку", "Z принял последний тест"... и я не знаю, как это сделать.

Интересно, что является лучшим решением:

Решение 1, также известное как "регистрация".

Выделенная таблица "Уведомление". Я добавляю строки в эту таблицу каждый раз, когда происходит оповещение (добавление друзей, ответы на вопросы и т.д.). Таблица "Уведомление" имеет поля, которые содержат различную информацию в зависимости от того, какой тип уведомления добавлен в таблицу.

Хорошо: простота написания кода, разделение между функцией уведомлений и "обычными" функциями, не слишком много ресурсов, когда мне нужно читать таблицу.

Плохо: таблица уведомлений будет, вероятно, очень большой (я думаю, что я добавлю 10 000 строк/день в таблицу), "дублированная" информация: информацию в таблице уведомлений можно найти во всех других таблицах, используя дату/список/что угодно сравнение.

Решение 2, иначе "смотреть везде".

Каждый раз, когда мне нужно показать список уведомлений или показать количество новых уведомлений, я просматриваю все соответствующие таблицы, сравниваю дату и т.д., Чтобы узнать, произошло ли что-то новое с момента последней проверки пользователем уведомления.

Хорошо: не слишком большая таблица по сравнению с решением 1, нет "избыточности" информации.

Плохо: я боюсь из-за количества пользователей (~ 1k+), он заставляет сервер взорваться, потому что он требует ресурсов/времени, немного сложнее для кодирования/обслуживания.

Можете ли вы сказать мне, что вы думаете, что лучше и почему, или у вас есть решение, которое я не представлял?

Спасибо =)

Изменить: Допустим, я использую действительно базовый дизайн БД: у пользователей есть друзья, они могут делать тесты.

1 таблица для списка пользователей, список опросов,

1 проверка таблицы & lt; → отношение пользователя,

1 пользователь таблицы & lt; → пользователь для дружбы.

Каждый раз, когда пользователь посещает свой собственный профиль, он может видеть, что произошло: новый опрос & lt; → отношение пользователя, новый пользователь & lt; → отношение пользователя и т.д. Как бы вы разработали такое уведомление?

Ответ 1

Создайте системную очередь, каждое сообщение, добавленное в эту очередь, содержит список "потребителей" и контента. Основной насос сообщений обрабатывает каждое сообщение и отправляет сообщение всем потребителям.

Давайте скажем, что 2 человека дружат друг с другом. Вы добавляете сообщение в основную системную очередь, что A дружит с B, а потребители - это A и B. Когда ваше сообщение "pump" (процессор) видит это сообщение, оно добавляет его в очередь A и очередь B. So теперь пользователь A и пользователь B имеют новое сообщение о том, что они друзья. В свою очередь, у каждого пользователя есть процессор сообщений, поэтому, когда он видит сообщение "Я дружу с [кем-то]", он обрабатывает это, добавляя новую запись в "стену", видимую друзьям A, что "A дружит с B" и т.д.

Это слишком упрощенно, но, надеюсь, показывает, как для этого можно использовать очереди сообщений (очень похожая система используется в качестве интерфейса пользовательского интерфейса Windows), поэтому уже существует существующий пример, и есть много синхронизированных шаблонов очереди сообщений, которые вы можете использовать.

Отдых зависит от вас.

Ответ 2

Действительно, это подпадает под , как я могу создать категорию вопроса?...

Реализация зависит от дизайна, где он будет идти в будущем, и среды, в которой вы будете реализовывать. Вы можете выбрать реализацию twitter-esque, систему поддержки XML, реляционных баз данных, Hadoop и множество других.

Хорошее знание веб-технологий, опыта, проб и ошибок - единственный способ сконструировать любую функцию с уверенностью, что вы делаете это правильно (ish).

Каковы ваши потребности в производительности? Уровни трафика? Пользовательские требования? Вы хотите распространять позже (например, через веб-узлы?).

Ваш вопрос должен быть более конкретным.

Я лично имел бы таблицу "типов уведомлений", действующую как enum..., а затем таблица user < > notification, обрабатывающая связь между уведомлением и пользователем.

С хорошим кодированием вы можете объединить таблицу уведомлений пользователя < > уведомлений на многих серверах и клавишу на идентификаторе пользователя или аналогичном... и реплицировать таблицу типов по каждому из этих узлов для локального кэша/ссылки. Что-то вроде этого.

Ответ 3

Я предлагаю использовать простые уведомления. Нет типа уведомления или что-то еще.

Уведомления
-id
-message
-href (Ссылка, чтобы перейти, когда пользователь нажимает уведомление)
-receiverUser
-date

Пример использования: Джону (34) понравилась фотография Марии (47). (Мы отправляем уведомление Мэри)

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

Ответ 4

Такие сервисы, как AWS и Azure, предоставляют платформы уведомлений. Если вы используете какой-либо из них, вам не нужно беспокоиться о структурах таблиц. Все, что вам нужно, это вызвать уведомление из другой точки вашего приложения.

Например, когда пользователю нравится что-то от другого пользователя, ваше приложение может инициировать событие отправки (может быть отправлено тысячам пользователей одним вызовом API). API сохранит и перенаправит запись конечному пользователю или пользователям.

Это хорошо работает для нас.

Надеюсь, что это помогает другим, ищущим подобные решения.