Когда данные сохраняются на диск при использовании IReliableDictionary2?

Question

У нас есть AC # надежный словарь коллекции, который реализует IReliableDictionary2 и заметил что-то странное из-за ошибки сериализации.

У нас есть класс X, который содержит другой класс, класс Y. Мы забыли добавить сериализацию в класс Y. Но в течение нескольких дней после того, как класс X был добавлен в надежный словарь сбора, класс Y также был там, когда мы получилиэкземпляр X.

По-видимому, надежный словарь коллекции был только в памяти, но в какой-то момент коллекция была сохранена на диске, именно в этот момент класс Y вернулся нулевым, так как он не был добавлен в сериализациюс [DataMember].

Итак, вопрос в том, когда надежная коллекция сохраняется на диске?Есть ли программный контроль над этим?Или это какой-то кластерный параметр?

Answer 1

Когда вы работаете с ReliableCollections, каждая операция (т.е. AddAsync) выполняет следующие действия:

1. Обновляет ITransaction локальное хранилище (для предоставления read-your-own-writes semantics)
2. Сериализует значения и обновляет локальный журнал операций (сохраняется).
3. Отправьте эти байты во все вторичные реплики, чтобы убедиться, что они имеют одинаковую информацию.

Тогда, когда ITransactionподтверждено, запись commit добавляется в журнал и отправляется во все вторичные реплики.В тот момент, когда quorum подтверждает фиксацию, операция считается выполненной (см. здесь для получения дополнительной информации).

Таким образом, в целом информация все время сериализуется.

Причина, по которой вы увидели «правильные» результаты, заключается в том, что большую часть времени вы работаете с одной и той же репликой - первичная реплика (это сделано потому, что только первичная реплика может изменять состояние) ивсе операции чтения / записи из одной и той же реплики возвращали правильных значений.

Хитрость в том, что Service Fabric может перемещать реплики между узлами, т. е. представьте, что ваша основная реплика была на Node1.Все ваши операции чтения и записи были в порядке, но затем Service Fabric решила переместить вашу основную реплику на Node2 - это приводит к новой простой реплике на Node2, которая получает initialized путем передачи сериализованных данных в нее.Когда реплика инициализируется, реплика на Node1 понижается, а реплика на Node2 повышается.Теперь все ваши запросы относятся к серверу Node2, а не Node1 (см. здесь и здесь для получения дополнительной информации о жизненном цикле службы и реплики).

Answer 2

Основной вопрос: When is data persisted to disk when using IReliableDictionary2? уже имеет много ответов при переполнении стека и в документах.

Как данные в надежном словаре в Azure Service Fabric сохраняются на диске

Этот ответ подробно описывает, как данные изменяются и реплицируются: Недостатки CommitAsync () без каких-либо изменений в коллекции

А этот ответ отвечает за то, как они хранятся в памяти: Azure Service Fabric надежные коллекции и память

Причина возникновения проблемы в вашем случае ясна:

1. Вы неправильно сериализовали данные, когдаданные реплицируются на другие реплики, пропадает информация
2. Как объясняется во многих других вопросах и публикациях, данные хранятся в памяти, поэтому нет смысла записывать эти данные на диск и читать их в память, оригиналхранение копии в памяти с полными данными, которые отличаются от реплицированных.
3. Если вторичная реплика становится первичной, данные, загруженные в память, будутотсутствует информация.
4. Существует также «кеширование» для надежного словаря, который сбрасывает неиспользуемые «холодные» данные на диск для освобождения памяти, это одно из улучшений, которые они сделали, чтобы лучше использовать память, когда бы ваши данные не использовалисьна долгое время не используются, они удаляют из памяти значения словаря, а не ключи, чтобы освободить место, при повторном доступе к данным они будут загружены с диска.

Answer 3

Вопрос должен быть наоборот: когда сервисная структура читает коллекцию с диска?

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