Переход между службой состояния и внешним постоянством в лазурной службе

Ткань Azure Service Fabric, по-видимому, ориентирована на сценарии, в которых все данные могут вписываться в ОЗУ, а постоянство используется в качестве хранилища резервных копий. Надежные службы предназначены для хранения информации в "Надежных коллекциях", в которой используется система регистрации log-checkpoint , где записываемая информация записывается в ОЗУ. Между тем, для Надежных Акторов поставщик состояния актора по умолчанию является" распределенным хранилищем ключевого значения, предоставляемым платформой Service Fabric ". Это, по-видимому, указывает на то, что будут применяться те же ограничения.

Однако могут быть ситуации, в которых вы хотели бы использовать Сервисную Ткань для "горячих данных", но пишите "холодные данные" в какую-то постоянную память. Каковы наилучшие методы обработки этого перехода?

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

Возможный ответ заключается в том, что Service Fabric уже делает это. Возможно, надежный словарь имеет встроенный механизм переключения между хранящимся в памяти хранилищем и постоянным хранилищем.

Или, может быть, ответ заключается в том, что нужно управлять этим. Один из подходов может заключаться в том, чтобы актер следил за тем, как он "горячий", и, при необходимости, переключая его хранилище персистентности. Но это жертвует одним из преимуществ модели Actor, автоматического распределения и освобождения актеров. Аналогичным образом мы можем периодически удалять элементы из надежного словаря и добавлять его в какой-либо другой хранилище сохранения, а затем добавлять их обратно. Опять же, это требует знания того, когда имеет смысл сделать переход.

Несколько примеров могут помочь в кристаллизации этого:

(1) Предположим, что мы реализуем многопользовательскую игру со множеством разных "комнат". Нам не нужны все комнаты в памяти сразу, но мы должны перенести их в память и использовать локальное сохранение в качестве резервной копии, когда игроки присоединятся к ним.

(2) Предположим, что мы реализуем только B-Tree с добавлением только как часть базы данных. Искушение состояло бы в том, чтобы каждый B-Tree node был субъектом с точки зрения состояния. Мы хотим, чтобы горячие b-деревья оставались в памяти, но, конечно, весь индекс не может быть в памяти. Похоже, что это основной сценарий, который уже реализован для таких вещей, как DocumentDB, но мне не ясно, из документации, как это можно сделать.

Связанный вопрос, который я нашел, здесь. Но этот вопрос фокусируется на том, когда использовать Azure Service Fabric и внешние сервисы. Мой вопрос заключается в том, есть ли необходимость перехода между ними, или у Azure Service Fabric уже есть все возможности, необходимые здесь.

Ответы

Ответ 1

Поставщик состояния хранилища ключей не требует, чтобы все хранилось в памяти. Этот провайдер фактически сохраняет состояние всех участников на локальном диске, и состояние также реплицируется на локальный диск на других узлах. Таким образом, хранилище KVS считается постоянным и надежным хранилищем.

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

Кроме того, KVS не является единственным встроенным государственным провайдером. У нас также есть VolatileActorStateProvider (http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/#actor-state-provider-choices). Это поставщик, который хранит все в памяти.

Ответ 2

KvsActorStateProvider действительно сохраняет состояние актера в KeyValueStore, который похож на структуру ReliableDictionary.

Первый вопрос, который я задал бы, должен ли вам относить состояние старых актеров к холодному хранению? Ограничение хранения всего в памяти не ограничивает вас общим количеством участников, а общее количество на каждую реплику. Поэтому сначала вы должны рассмотреть стратегию разделения, чтобы ваши участники были распределены по нескольким различным репликам. По мере роста ваших требований вы можете добавить в кластер больше машин, и ServiceFabric будет организовывать перемещение реплик на новые машины. Для получения дополнительной информации о разделении службы Actor см. http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/

Если вы хотите использовать холодное хранилище через некоторое время, у вас есть несколько вариантов. Во-первых, вы можете украсить своих актеров обычным ActorStateProviderAttribute, который возвращает вашу собственную реализацию IActorStateProvider, которая может обрабатывать упорство по вашему выбору.

В качестве альтернативы вы можете полностью справиться с этим в своей реализации. Подключитесь к " Напоминание актера" в течение определенного времени в будущем, для сериализации состояния и хранения в холодном хранилище, например, для блочного или табличного хранилища и исключения из свойства State. Активация ActivateAsync затем может использоваться для извлечения этого состояния из автономного хранилища и десериализации.