Лучший метод объединения каналов в Google App Engine - PullRequest
Новая
       21

Лучший метод объединения каналов в Google App Engine

15 голосов
/ 16 ноября 2011

Кажется, что единственный способ сделать API-интерфейс GAE Channel финансово жизнеспособным - это внедрить какой-то механизм объединения (один из старших менеджеров по продуктам приложений даже сказал мне об этом, когда я отправил им электронное письмо о непомерной цене), чтобы повторно использовать каналы, которыееще не истек.

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

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

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

Backend Instance - Вероятнолучший вариант с точки зрения надежности, но теперь затраты на запуск бэкэнда съедят все сбережения на реализациюПрежде всего, пул!

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

Ответы [ 2 ]

8 голосов
/ 21 декабря 2011

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

Создайте модуль taskpool со следующим API. 

client_id, token = taskpool.get()

# Setup a heartbeat in the client JS, maybe every minute. 
# Also call this every time the client indicates presence
taskpool.ping(client_id)

taskpool.release(client_id)

Реализация:

  • Сохраните client_id и token в объекте со статусом, указывающим, используется ли он, время последнего пинга и время создания. Пусть client_id будет ключом. Также рассмотрите возможность использования NDB . Бесплатное memcaching.

get() проверяет наличие неиспользованных токенов и возвращает один, если находит его. В противном случае создайте новый, сохраните и верните его.

ping() обновляет время последнего пинга для этого токена. Вместо того, чтобы опрашивать, пусть клиент отправляет пинг каждый раз [сердцебиение].

release() помечает токен как неиспользованный.

Запускайте задание / cron каждые [сердцебиение] секунды, чтобы найти токены, которые не получили пинг за некоторое время, - и установите их как неиспользуемые.

Когда клиенты сообщают о закрытом токене, выполните get().

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

Я обновлю этот ответ, если и когда напишу это как библиотеку.

2 голосов
/ 05 июля 2013

По мнению службы поддержки Google App Engine, токены канала не могут быть использованы повторно.Не рекомендуется использовать их повторно.

Можно ли повторно использовать каналы Google App Engine?

...