Основанная на Memcache очередь сообщений? - PullRequest
Новая
       10

Основанная на Memcache очередь сообщений?

10 голосов
/ 09 марта 2009

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

Я узнал концепцию очереди memcache из этого сообщения в блоге :

Все сообщения сохраняются с целым числом в качестве ключа. Есть один ключ, который имеет следующий ключ, и тот, который имеет ключ самого старого сообщения в очереди. Для доступа к ним в качестве атомарного метода используется метод увеличения / уменьшения, поэтому есть два ключа, которые действуют как блокировки. Они увеличиваются, и если возвращаемое значение равно 1, процесс блокируется, в противном случае он продолжает увеличиваться. Как только процесс завершен, он устанавливает значение обратно в 0. Простой, но эффективный. Одно предостережение в том, что целое число будет переполнено, поэтому существует некоторая логика, которая устанавливает используемые ключи в 1, как только мы приближаемся к этому пределу. Поскольку операция приращения является атомарной, блокировка необходима только в том случае, если используются две или более кэш-памяти (для избыточности), чтобы синхронизировать их.

У меня вопрос: есть ли служба очереди сообщений на основе memcache, которая может работать в App Engine?

Ответы [ 5 ]

9 голосов
/ 09 марта 2009

Я бы очень осторожно использовал Memcache в Google App Engine. Вы правы, что беспокоитесь о «неожиданном удалении кэша».

Google ожидает, что вы будете использовать memcache для кэширования данных, а не для хранения данных. Они не гарантируют хранение данных в кеше. Из документации GAE :

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

Редактировать: Всегда есть Простая служба очередей Amazon . Однако это может не соответствовать уровням цена / производительность:

  1. Будет задержка звонка с Google на серверы Amazon.
  2. В конечном итоге вы заплатите дважды за весь трафик данных - заплатите за то, чтобы он покинул Google, а затем снова заплатите за него, чтобы войти в Amazon.
4 голосов
/ 24 апреля 2009

Я запустил Simple Python Memcached Queue, это может быть полезно: http://bitbucket.org/epoz/python-memcache-queue/

1 голос
/ 06 августа 2012

Почему бы не использовать очередь задач:
https://developers.google.com/appengine/docs/python/taskqueue/
https://developers.google.com/appengine/docs/java/taskqueue/

Похоже, проблема решена без вероятной потери сообщений в очереди на основе Memcached.

1 голос
/ 09 марта 2009

Если вы довольны возможностью потери данных, обязательно продолжайте. Имейте в виду, однако, что хотя memcache, как правило, имеет меньшую задержку, чем хранилище данных, как и все остальное, он пострадает, если у вас будет высокий уровень атомарных операций, которые вы хотите выполнить с одним элементом. Это не проблема хранилища данных - это просто проблема с сериализацией доступа.

Если этого не сделать, SQS от Amazon кажется жизнеспособным вариантом.

0 голосов
/ 09 марта 2009

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

Хранилище данных должно быть более чем достаточно быстрым для того, что вам нужно - у вас просто будет простая модель Job, которая будет более гибкой, чем memcache, поскольку вы не ограничены парами ключ / значение

...