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

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

KvsActorStateProvider действительно сохраняет состояние актера в хранилище KeyValueStore, которое является аналогичной структурой для ReliableDictionary.

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

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

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