Каков наилучший метод для очереди чувствительных ко времени сообщений с PHP / MySQL? - PullRequest
1 голос
/ 22 марта 2010

Я создаю систему SMS-вызовов и ответов в новом приложении, которое получает сообщение через шлюз агрегатора, проверяет его на наличие функциональных ключевых слов (run, stop, ask и т. Д.), А затем обрабатывает его соответствующим образом (сохраняет в базе данных). , вернуть ответ или выполнить задание на основе авторизации пользователей). В настоящее время он работает нормально, так как пользователей всего несколько, но я думаю, что по мере его масштабирования у него будет больше проблем. В настоящее время мы запускаем его на одной DV-машине (mediatemple base dv).

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

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

1 Ответ

1 голос
/ 22 марта 2010

«Самый быстрый» и «самый надежный» не обязательно сочетаются друг с другом: часто один или другой.

О memcached и базе данных вы должны знать, что memcached - это механизм кэширования , а не механизм хранения данных.


Это означает, что его нельзя использовать для хранения данных, которые вы не можете восстановить:

  • в случае сбоя системы (например, сбой / перезагрузка) , вы потеряете то, что было в memcached - в то время как база данных более способна к восстановлению
  • если ОЗУ недостаточно для хранения данных, memcached удалит некоторые старые элементы из кэша, даже если вы не просили об этом

memcached отлично подходит для создания распределенного кластера кэширования; но не должны использоваться для хранения важных данных, которые вы не можете позволить себе потерять.

...