Memcache 기반 메시지 큐?

Question

멀티 플레이어 게임을 작업 중이며 메시지 대기열이 필요합니다 (예기치 않은 캐시 퇴거가 없다고 가정 할 때 메시지, 메시지 꺼내기, 메시지 출력 또는 삭제 된 메시지가 필요하지 않음). 다음은 알고있는 Memcache 기반 대기열입니다.

• memcacheq : http://memcachedb.org/memcacheq/
• 찌르레기: http://rubyforge.org/projects/starling/
• Depcached : http://www.marcworrell.com/article-2287-en.html
• 참새: http://code.google.com/p/sparrow/

나는 Memcache 대기열의 개념을 배웠다 이 블로그 게시물:

모든 메시지는 정수로 키로 저장됩니다. 다음 키가있는 하나의 키와 대기열에서 가장 오래된 메시지의 키가있는 키가 있습니다. 이러한 액세스를 위해 증분/감소 방법은 원자로 사용되므로 잠금으로 작동하는 두 개의 키가 있습니다. 그것들은 증가하고, 반환 값이 1 인 경우 프로세스에 잠금이 있고 그렇지 않으면 계속 증가합니다. 프로세스가 완료되면 값을 0으로 되돌립니다. 단순하지만 효과적입니다. 한 가지 경고는 정수가 오버플로 나오기 때문에 해당 한계에 가까워지면 중고 키를 1으로 설정하는 논리가 있습니다. 증분 작업이 원자이므로, 잠금 장치를 동기화하기 위해 둘 이상의 멤코치를 사용하는 경우에만 잠금이 필요합니다.

내 질문은 App Engine에서 실행할 수있는 Memcache 기반 메시지 큐 서비스가 있습니까?

Answer 1

I would be very careful using the Google App Engine Memcache in this way. You are right to be worrying about "unexpected cache evictions".

Google expect you to use the memcache for caching data and not storing it. They don't guarantee to keep data in the cache. From the GAE Documentation:

By default, items never expire, though items may be evicted due to memory pressure.

Edit: There's always Amazon's Simple Queueing Service. However, this may not meet price/performance levels either as:

1. There would be the latency of calling from the Google to Amazon servers.
2. You'd end up paying twice for all the data traffic - paying for it to leave Google and then paying again for it to go in to Amazon.

Answer 2

I have started a Simple Python Memcached Queue, it might be useful: http://bitbucket.org/epoz/python-memcache-queue/

Answer 3

If you're happy with the possibility of losing data, by all means go ahead. Bear in mind, though, that although memcache generally has lower latency than the datastore, like anything else, it will suffer if you have a high rate of atomic operations you want to execute on a single element. This isn't a datastore problem - it's simply a problem of having to serialize access.

Failing that, Amazon's SQS seems like a viable option.

Answer 4

Why not use Task Queue:
https://developers.google.com/appengine/docs/python/taskqueue/
https://developers.google.com/appengine/docs/java/taskqueue/

It seems to solve the issue without the likely loss of messages in Memcached-based queue.

Answer 5

Until Google impliment a proper job-queue, why not use the data-store? As others have said, memcache is just a cache and could lose queue items (which would be.. bad)

The data-store should be more than fast enough for what you need - you would just have a simple Job model, which would be more flexible than memcache as you're not limited to key/value pairs