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

Question

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

• Мемкэш Вопрос: http://memcachedb.org/memcacheq/
• Скворец: http://rubyforge.org/projects/starling/
• Депкачировано: http://www.marcworrell.com/article-2287-en.html
• Воробей: http://code.google.com/p/sparrow/

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

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

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

Answer 1

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

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

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

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

1. При звонках с серверов Google на серверы Amazon может возникнуть задержка.
2. В конечном итоге вам придется платить дважды за весь трафик данных: платить за его выход из Google, а затем снова платить за его передачу в Amazon.

Answer 2

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

Answer 3

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

В противном случае SQS от Amazon кажется жизнеспособным вариантом.

Answer 4

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

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

Answer 5

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

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