Как реализовать поток активности в социальной сети

Question

Как реализовать поток активности в социальной сети

Я разрабатываю свою собственную социальную сеть, и я не нашел в интернете примеров осуществления поток действий пользователей... Например, как фильтровать действия для каждого пользователя? Как хранить события действия? Какую модель данных и объектную модель я могу использовать для потока действий и для самих действий?

695 6

design-patterns architecture stream social-networking

6 ответов:

Comments

Ничего не найдено.

casey · Accepted Answer · 2015-03-10 20:36:01

резюме: для около 1 миллиона активных пользователей и 150 миллионов сохраненных действий, я держу его просто:

используйте реляционную базу данных для хранения уникальных действий (1 запись на действие / "то, что произошло") сделайте записи максимально компактными. Структура, позволяющая быстро захватить пакет действий по идентификатору действия или с помощью набора идентификаторов друзей с ограничениями по времени.

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

запрос Redis, чтобы получить поток активности для любого пользователя, а затем захватить соответствующие данные из БД по мере необходимости. Вернитесь к запросу БД по времени, если пользователю нужно просмотреть далеко назад во времени (если вы даже предлагаете это)

Я использую простую старую таблицу MySQL для работы с примерно 15 миллионами деятельности.

это выглядит примерно так:
id             
user_id       (int)
activity_type (tinyint)
source_id     (int)  
parent_id     (int)
parent_type   (tinyint)
time          (datetime but a smaller type like int would be better) 
activity_type говорит мне тип деятельности,source_id говорит мне запись, что деятельность связана С. Поэтому, если тип действия означает "добавлено избранное", то я знаю, что source_id ссылается на идентификатор любимой записи.

The parent_id/parent_type полезны для моего приложения - они говорят мне, что мероприятие относится к. Если бы книга была фаворитом, то parent_id/parent_type сказал бы мне, что действие относится к книге (типу) с заданным первичным ключом (id)

индекс I о (user_id, time) и запрос для действий, которые user_id IN (...friends...) AND time > some-cutoff-point. Выбрасывание идентификатора и выбор другого кластеризованного индекса может быть хорошей идеей - я не экспериментировал с этим.

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

для более быстрого доступа в последнее время я экспериментировал с Рэдис. Redis хранит все свои данные в памяти, поэтому вы не можете поместить туда все свои действия, но вы можете хранить достаточно для большинства часто посещаемых экранов на вашем сайте. Последние 100 для каждого пользователя или что-то подобное. С Redis в миксе, это может работать следующим образом:

создайте свою запись активности MySQL

для каждого друга пользователя, который создал действие, нажмите идентификатор на список активности в Redis.

обрезать каждый список до последнего X элементов

Redis работает быстро и предлагает способ конвейеризации команд через одно соединение - поэтому выталкивание активности до 1000 друзей занимает миллисекунды.

для более подробного объяснения того, о чем я говорю, см. Пример Twitter Redis:http://redis.io/topics/twitter-clone

Обновление Февраль 2011 у меня есть 50 миллионов активная деятельность на данный момент и я ничего не изменил. Одна хорошая вещь о делать что-то подобное этому является то, что он использует компактные, небольшие строки. Я планирую внести некоторые изменения, которые будут включать в себя гораздо больше мероприятий и больше запросов этих мероприятий, и я определенно буду использовать Redis, чтобы ускорить работу. Я использую Redis в других областях, и это действительно хорошо работает для определенных видов проблем.

Обновление Июля 2014 мы поднялись до 700 тысяч ежемесячно активный пользователь. В течение последних нескольких лет я использую Redis (как описано в маркированном списке) для хранения последних 1000 идентификаторов активности для каждого пользователя. Обычно в системе есть около 100 миллионов записей активности, и они все еще хранятся в MySQL и по-прежнему имеют тот же макет. Эти записи позволяют нам уйти с меньшим количеством памяти Redis, они служат в качестве записи данных о деятельности, и мы используем их, если пользователям нужно вернуться на страницу назад во времени, чтобы найти что-то.

это был не a умное или особенно интересное решение, но оно сослужило мне хорошую службу.

Nicolò Martini · Accepted Answer · 2009-11-23 00:28:19

это моя реализация потока активности, используя mysql. Существует три класса: Activity, ActivityFeed, Subscriber.

Activity представляет запись activity, и ее таблица выглядит следующим образом:
id
subject_id
object_id
type
verb
data
time
Subject_id - это идентификатор объекта, выполняющего действие, object_id идентификатор объекта, который получает действие. type и verb описывает само действие (например, если пользователь добавляет комментарий к статье, они будут "комментарий" и "создано" соответственно), данные содержат дополнительные данные во избежание объединения (например, он может содержать имя и фамилию субъекта, название статьи и url, тело комментария и т.д.).

каждое действие принадлежит одному или нескольким ActivityFeeds, и они связаны таблицей, которая выглядит следующим образом:
feed_name
activity_id
в моем приложении у меня есть один канал для каждого пользователя и один канал для каждого элемента (обычно статьи в блоге), но они могут быть все, что вы хотите.

A Подписчик обычно является пользователем вашего сайта, но он также может быть любым объектом в вашей объектной модели (например, статья может быть подписана на feed_action его создателя).

каждый подписчик принадлежит к одному или нескольким ActivityFeeds, и, как и выше, они связаны с помощью таблицы ссылок такого рода:
feed_name
subscriber_id
reason
The reason поле здесь объясняет, почему подписчик подписался на канал. Например, если пользователь закладывает сообщение в блоге, причиной является "закладка". Этот помогает мне позже в фильтрации действий для уведомлений пользователей.

чтобы получить действие для подписчика, Я делаю простое объединение трех таблиц. Соединение происходит быстро, потому что я выбираю несколько видов деятельности благодаря WHERE состояние, которое выглядит как сейчас -time > some hours. Я избегаю других соединений благодаря Полю данных в таблице активности.

дальнейшее объяснение на

sntran · Accepted Answer · 2012-02-14 16:48:46

существует текущий формат для потока активности, который разрабатывается группой хорошо знакомых людей.

http://activitystrea.ms/.

в принципе, каждое действие имеет субъекта (который выполняет действие), глагол (действие действия), объект (на котором действует субъект) и цель.

например: Макс опубликовал ссылку на стену Адама.

их спецификация JSON достигла версии 1.0 во время запись, которая показывает шаблон для действия, которое вы можете применить.

их формат уже был принят BBC, Gnip, Google Buzz Gowalla, IBM, MySpace, Opera, Socialcast, Superfeedr, TypePad, Windows Live, YIID и многие другие.

Nicolò Martini · Accepted Answer · 2017-05-23 15:26:24

Я думаю, что объяснение того, как система уведомлений работает на больших веб-сайтах, можно найти в вопросе переполнения стека как сайты социальных сетей вычисляют обновления друзей?, в Джереми Стены'ы ответ. Он предлагает использовать Сообщение Qeue и он указывает на два программного обеспечения с открытым исходным кодом, которые реализуют его:

RabbitMQ

Apache QPid

Смотрите также вопрос каков наилучший способ реализации потока социальной активности?

Cagatay Kalan · Accepted Answer · 2012-04-05 03:47:22

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

в любом случае, это действительно сложная задача, мой друг, если вы после высокой производительности и масштабируемой системы. Но, конечно, некоторые щедрые инженеры поделились своим опытом по этому поводу. LinkedIn недавно сделал свою систему очереди сообщений Kafka открытым исходным кодом. До этого Facebook уже предоставлено Scribe сообществу с открытым исходным кодом. Кафка написан на Scala, и сначала требуется некоторое время, чтобы заставить его работать, но я протестировал с несколькими виртуальными серверами. Это действительно быстро.

http://blog.linkedin.com/2011/01/11/open-source-linkedin-kafka/

http://incubator.apache.org/kafka/index.html

Mafuba · Accepted Answer · 2013-06-19 05:47:46

вместо того, чтобы сворачивать свой собственный, Вы можете обратиться к стороннему сервису, используемому через API. Я начал один называется Collabinate (http://www.collabinate.com), который имеет бэкэнд графической базы данных и некоторые довольно сложные алгоритмы для обработки больших объемов данных в очень параллельной, высокопроизводительной манере. Хотя он не имеет широты функциональных возможностей, которые говорят, что Facebook или Twitter делают, этого более чем достаточно для большинства случаев использования, когда вам нужно создать активность потоки, социальные каналы или функции микроблогов в приложение.