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

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

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

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

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

Ответы

Ответ 1

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

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

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

Изменить: Всегда Amazon Simple Queuing Service. Однако это может не соответствовать уровню цены/производительности либо как:

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

Ответ 3

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

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

Ответ 5

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

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