Следуйте за механизмом с php: какую стратегию использовать? - PullRequest
Новая
       4

Следуйте за механизмом с php: какую стратегию использовать?

0 голосов
/ 21 сентября 2010

Я пытаюсь создать механизм слежения, подобный твиттеру.Пользователь выполняет действие.Мы составляем список всех последователей этих пользователей, а затем заполняем все их потоки некоторой информацией.Поскольку это может занять некоторое время (если у вас есть 10 000 подписчиков, в которые вставляется информация из 10 000 потоков, т. Е., Возможно, 10 000 вызовов SQL), я хочу убедиться, что это выполняется в фоновом режиме, а пользователь, выполняющий действие, может перейтис его жизнью.

Итак, стратегия, которую я рассматриваю, такова:

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

Мысли?Я также поиграл с использованием очереди, что-то вроде SQS, но этот подход звучит так, как будто он также может работать?Кроме того, у меня есть преимущество (для меня) в том, что его проще тестировать локально и легче запускать на хостах, отличных от ec2.

И если это хороший подход, как мне открыть скрипт php из скрипта php?Может ли это быть так просто, как (если скрипт php живет по URL-адресу), чтобы получить URL-адрес, где этот скрипт живет?

Ответы [ 2 ]

3 голосов
/ 21 сентября 2010

То, как это описано, звучит так, как будто вы хотите скопировать / продублировать сообщение первого пользователя для всех, кто следует за этим пользователем?Это будет кошмар для хранения данных.

Вы должны взглянуть на это с другой точки зрения.Рассмотрим следующую модель:

Пользователь А публикует, что он ел на завтрак.Это сохраняется один раз в таблице с его идентификатором пользователя.

Пользователь B смотрит на свой «поток».Это динамически создаваемый список сообщений.На данный момент Пользователь B подписан на 50 человек.Скрипт пользователя B получит первые 50 последних сообщений того, за кем он следит, и отобразит их для него в своем «потоке»

С этой моделью у вас никогда не будет более одного поста на пользователя на одно легкомысленное обновление завтрака.Кроме того, число подписчиков не увеличивает время обработки, необходимое для публикации твита.Я имею в виду твит.

Разъяснение

Вам просто нужно сделать некоторую нормализацию.Таким образом, у вас будет таблица пользователей, таблица users_following и таблица публикаций.Запрос будет выглядеть примерно так: 

SELECT posts.* FROM users_following
         LEFT JOIN posts ON posts.user_id = users_following.followed
         WHERE users_following.follower = $idOfUserB
         ORDER BY posts.created LIMIT 50;
0 голосов
/ 22 сентября 2010

Если вы хотите, чтобы ваш сайт вообще масштабировался.

  • Сначала вам нужно использовать очередь сообщений, например, например redis / beanstalkd / gearmand.
  • Во-вторых, вам нужно выполнять свои операции в памяти , используя, например, redis / memcached.Убедитесь, что у вас достаточно памяти для хранения активного набора данных в memory .

(если у вас есть 10 000 подписчиков, это 10000 потоков для вставки информации, т.е. 10000 вызовов SQLвозможно)

10 000 вызовов SQL имеет сбойный кит, записанный поверх него.Я бы не стал использовать MySQL (или, по крайней мере, использовать его с memcached) для такого приложения, но использовал бы redis.Храните активный набор данных в памяти.Сохраняйте модель данных максимально простой.

И если это хороший подход, как мне открыть скрипт php из скрипта php?

Не делайтетот.Добавьте сообщения в список блокировки через lpush и прочитайте их через blpop (процесс демона).Сначала я заполнил бы список онлайн-пользователей, а затем - список офлайн-пользователей.Оффлайн пользователи не против задержки, потому что они не в сети.Вы бы поместили ссылку на ключ в список всех пользователей, следующих за этим человеком, и получили бы все ключи через mget.

Может ли это быть так просто, как (если скрипт php живет по URL), выполнить getна URL, где живет этот скрипт?

Снова не вызывайте URL, а используйте очередь сообщений.Вызов URL приведет к нежелательным накладным расходам.

Отлично.Вернуться к SQL :) Это будет быстро, даже если вы подписаны на 500 человек?-

SQL даст вам большой сбой китов на большой нагрузке.По крайней мере, вам понадобится memcached!Но я бы вместо этого использовал redis .

...