Каков наилучший (масштабируемый, быстрый, надежный) подход для реализации ленты операций, очереди сообщений, СУБД или баз данных NoSQL? - PullRequest
Новая
       35

Каков наилучший (масштабируемый, быстрый, надежный) подход для реализации ленты операций, очереди сообщений, СУБД или баз данных NoSQL?

2 голосов
/ 20 января 2011

Мне нужно создать канал активности (поток? «Жизненный поток», чтобы быть более точным.) Для системы, аналогичной (такой же), похожей на многие популярные платформы социальных сетей. Моя первая попытка состояла в том, чтобы использовать СУБД, но быстро отказался от идеи из-за огромного количества необходимых соединений. Очистившись от других возможных (и более подходящих) подходов, я наткнулся на следующий пост:

Как сайты социальных сетей вычисляют обновления друзей?

Принимая советы по использованию очереди сообщений, я потратил некоторое время на изучение RabbitMQ и его протокола PubSubHubbub. И я постулировал следующий подход:

1) У каждого пользователя есть «тема»
2) Другие пользователи подписываются на тему
3) Когда пользователь выполняет какое-либо действие, публикуется сообщение, которое затем связывается (ссылки разрешены), форматируется (понятный человеку язык, ссылки и т. Д.) И агрегируется (X, Y и Z прокомментировали сообщение P) с PHP-скрипт.

Однако мне все равно придется проходить через каждое сообщение и обрабатывать его (если мой подход не будет полностью неверным). Итак, в чем разница между хранением всего в РСУБД и использованием очереди сообщений (кроме реализации протокола PubSubHubbub)?

Существуют ли более эффективные способы создания такой системы? (Если да, уточните)

Комментарии / предложения / Критика приветствуется. :)

Заранее спасибо!

P.S .: Есть интересная статья о том, как FriendFeed реализует ее (http://bret.appspot.com/entry/how-friendfeed-uses-mysql). Тем не менее, я чувствую, что «хакерство» выталкивает MySQL из его удобного домена (который является просто реляционными данными и какой смысл использовать RDBMS без реляционных данных?)

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

1 Ответ

2 голосов
/ 20 января 2011

Несколько советов, которые я хотел бы дать вам:

  • Не используйте СУБД, а базу данных в памяти (FAST), например, redis . Как вы надеетесь, вы согласитесь со мной из теста Redis , Redis довольно быстрый. В качестве еще одного замечания я хотел бы отметить, что установка redis - это детская игра :).

    сделать

Существует redis-клиент для PHP, который использует C, поэтому он также будет очень быстрым. - Если я вас правильно понимаю, вы думаете, что pubsubhubbub - это то же самое, что и очередь сообщений, но это не так:

Стороны (серверы), говорящие на Протокол PubSubHubbub можно получить почти мгновенные уведомления (через webhook callbacks) когда тема (фид URL), в котором они заинтересованы, обновлено.

по сравнению с очередью сообщений:

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

Вы можете подумать, что они одинаковы (у них есть некоторые сходства), но они не одинаковы. Для моей очереди сообщений я бы повторил (redis очень мощный, потому что он также имеет базовую очередь сообщений :)). Вы можете поместить сообщение (единицу работы) в очередь, используя rpush . 

rpush <name of queue> <message>

Тогда из ваших рабочих процессов вы можете получать сообщения из очереди, используя brpop (блокировка pop:)) 

brpop <name of queue> 0

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

php worker.php

Надеюсь, это для вас, надеюсь, и если у вас возникнут вопросы, я с удовольствием на них отвечу;)

...