Каковы стратегии для структур каналов Pusher в приложениях обновления социального статуса?

При создании социального приложения обычно следят за другими пользователями или темами как признак интереса к обновлениям со стороны пользователя или темы. Например, подписка на других пользователей в Твиттере, добавление в друзья других людей в Facebook или лайкование продукта или бренда на Facebook.

У Pusher есть концепция каналов, на которые вы подписаны. Каналы представляют собой удобочитаемую строку, которая предоставляет логический идентификатор информации (например, «имя-канала») и, следовательно, естественно предполагает, что в социальном приложении любые обновления о пользователе или теме должны отправляться по каналу, специфическому для этого. элемент (например, «userX-status-updates» или «myBrand-status-updates»).

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

Следовательно, каковы подходящие стратегии для структурирования каналов в приложении в стиле обновления социального статуса, которое использует Pusher?


publish-subscribe pusher
person leggetter    schedule 20.05.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Первое, что нужно уточнить, это то, что вам нужно сопоставление того, за кем вы следите, поэтому для целей этого ответа я предполагаю, что он хранится в БД на сервере. Также предполагалось, что обновления статуса запускаются следующим образом:

  1. Клиент (обновление статуса сообщений userX) -> Ваш сервер (очистить и проверить)
  2. Ваш сервер -> толкатель
  3. Pusher -> Клиенты (пользователи, заинтересованные в обновлениях от UserX)

Есть два возможных решения проблемы информационной архитектуры канала:

  1. Статус канала для каждого пользователя: пользователь подписывается на userX-status-updates канал для всех пользователей, на которых он подписан, и пользователи запускают события обновления в своем собственном канале обновления статуса.
  2. Пользователи, за которыми я следую за каналом: когда пользователь публикует обновление статуса, вы ищите, кто подписан на этого пользователя, и публикуете обновление на users-you-follow-updates канале.

Стратегия 1. является наиболее оптимальным решением, поскольку она сводит к минимуму взаимодействие с вашей собственной инфраструктурой и Pusher.

Вот подробности этих двух стратегий:

1. Статус канала на пользователя

Предполагается, что подписка на каналы стоит дорого, но это не совсем правильно. Каналы - это просто способ маршрутизации событий. Однако, если вы используете аутентифицированные каналы (частные и присутствие), вам необходимо аутентифицировать подписку через свой собственный сервер. . Если вы используете библиотеки Pusher WebSocket «из коробки», каждая подписка приведет к запросу на ваш сервер. Итак, пользователь подписывается на 1000 пользователей, которые отправляют 1000 запросов к вашему серверу.

Но для библиотеки pusher-js существует плагин multi-auth, который может пакетировать запросы аутентификации в один вызов.

Также существует BatchAuthorizer для библиотеки Pusher WebSocket Java, но это всего лишь пример решения для этого сценария. .

2. Пользователи, на которых я подписан на канал

Примечание: хотя это вариант, он, вероятно, подходит только для небольшого числа пользователей

В этом сценарии пользователь отправляет свое обновление статуса на сервер, сервер выполняет поиск пользователей, заинтересованных в обновлении, и запускает и обновляет даже канал для каждого заинтересованного пользователя.

Например, предоставьте пользователям UserA, UserB и UserC, каждый из которых будет подписываться на свой собственный канал обновлений; UserA-followers-updates, UserB-followers-updates и UserC-followers-updates соответственно. Если каждый из этих пользователей подписывается на UserZ, то, когда UserZ выполняет обновление статуса, это обновление публикуется на каждом из этих каналов.

Это также может показаться неэффективным, однако одно и то же событие можно запускать на 10 каналах одновременно. Таким образом, в приведенном выше примере потребуется только один вызов HTTP API Pusher для отправки обновления статуса всем заинтересованным пользователям. Дополнительную информацию о публикации многоканальных событий можно найти здесь.

person Community    schedule 20.05.2015