«Push» против «Pull» при разработке социальных сетей (твиттер, новостная лента fb и т. Д.) - PullRequest
Новая
       27

«Push» против «Pull» при разработке социальных сетей (твиттер, новостная лента fb и т. Д.)

0 голосов
/ 08 мая 2018

Мы все знаем о push (разветвление при записи) против pull (разветвление при чтении) при разработке системы feed / twitter в социальной сети.

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

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

Но в обоих случаях, какой механизм обычно используется, чтобы позволить человеку видеть обновленные каналы в РЕАЛЬНОМ ВРЕМЕНИ на веб-сайте? (Я думаю, что FB или твиттеру не понадобится, чтобы вы вручную обновляли страницу, чтобы видеть новые сообщения от друзей).

Допустим, Джон пишет сообщение, а в режиме push он помещает (пишет в SQL или в кэш redis) указатель этого сообщения на ленту всех друзей, как браузер одного из друзей узнает, что теперь есть обновление от Джона?

1 Ответ

0 голосов
/ 21 августа 2018

Я полагаю, у вас динамический (SPA) интерфейс.

В режиме вытягивания у вас есть два варианта:

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

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

В режиме push:

  • Периодически повторно извлекайте данные фидов (поскольку ваш запрос фида не сложен, он значительно снижает производительность).

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

Обычно люди используют гибридный подход:

  • Для производителей, у которых много активных потребителей (вошли в систему хотя бы раз в прошлом месяце), используйте метод pull.

  • Для производителей, у которых меньше активных потребителей, используйте метод push.

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

...