Как работают синглтоны в Google App Engine (или, в общем, в распределенной серверной среде)?

Я заинтригован, как работают синглеты в Google App Engine (или в любой распределенной серверной среде). Учитывая, что ваше приложение может работать в нескольких процессах (на нескольких компьютерах) сразу, а запросы могут быть перенаправлены с места, что на самом деле происходит под капотом, когда приложение делает что-то вроде: "CacheManager.getInstance()"?

Я просто использую (GAE) CacheManager в качестве примера, но, на мой взгляд, есть один экземпляр глобального приложения синглтона где-нибудь, так где он живет? Вызывается RPC? Фактически, как глобальное состояние приложения (например, сеансы) фактически обрабатывается вообще?

С уважением, Шейн

ОТВЕТЫ

Ответ 1

Синглеты в Java App Engine Java - это время выполнения, а не per-webapp. Их целью является просто обеспечить единую точку доступа к базовой службе (которая в случае с API-интерфейсом Memcache и Users доступна через RPC), но это чисто шаблон проектирования для библиотеки - нет ни одного одноадресного приложения где эти методы доступны.

Ответ 2

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

Вот некоторые примеры продуктов с распределенными функциями кеширования (большинство из них имеют документацию, описывающую компромиссы различных подходов очень подробно:

  • memcached - C с большим количеством клиентских API и языковых портов
  • Ehcache - OSS-кэш Java с широким внедрением
  • JBoss Cache - Еще одно популярное решение для Java OSS
  • Oracle Coherence (ранее Tangosol Coherence) - Вероятно, самый известный коммерческий кэш Java.
  • Кэш-память Indexus - популярное решение .Net OSS
  • NCache - Вероятно, самое популярное коммерческое решение для кэширования .Net.

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

Ответ 3

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

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

Документы GAE, похоже, поддерживают то, что они называют "Кэшированием приложений", которое по существу позволяет вам делать то же самое, но мне не ясно, из документов, независимо от того, делают ли они это, используя многопоточные веб-серверы, или какой-либо другой процесс кэширования, который работает вместе с веб-серверами.

Мне было бы интересно узнать, всегда ли CacheManager.getInstance() разрешает один и тот же объект, или же он только тот же объект для запросов, обрабатываемых одним и тем же веб-сервером. На самом деле это не имеет значения, поскольку он используется только для разговора с отдельным процессом memcached.