Apache Ignite : Конфигурация клиента и сервера

#c# #.net #ignite #gridgain

Вопрос:

У меня есть серверный узел, основанный на примере, упомянутом в https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/examples/ServerNode/Program.cs

Также в другом процессе у меня есть клиент с «ClientMode = true», как показано ниже.

         return new IgniteConfiguration(GetServerNodeConfiguration())
        {
            ClientMode = true
        };
 

В кэше будет храниться информация класса «Сотрудник», и я использую IBinarySerializer для сериализации классов «Сотрудник» и «Адрес», а сериализаторы добавляются в конфигурацию IgniteConfiguration, как показано ниже…

 IgniteConfiguration.BinaryConfiguration = new BinaryConfiguration
                {
                    TypeConfigurations = new List<BinaryTypeConfiguration>
                    {
                        new(typeof(Employee)){Serializer = new EmployeeSerializer()},
                        new(typeof(Address)){Serializer = new AddressSerializer()},
                    }
                }
 

Мои вопросы таковы…

  1. Нужно ли нам иметь классы «Сотрудник» и «Адрес» как на сервере, так и в клиентском коде? или я просто упоминаю о них на стороне клиента?
  2. Нужно ли нам иметь сериализаторы IBinarySerializer в конфигурации двоичных файлов ignite как на сервере, так и в клиентском коде? или я просто упоминаю о них на стороне клиента?

Работник

 public class Employee
{
    public Guid EmployeeId { get; set; }
    public string Name { get; set; }
    public Address Address { get; set; }
}
 

Адрес

 public class Address
{
    public string Street { get; set; }
    public string Zip { get; set; }
}
 

Реализации IBinarySerializer

 public sealed class EmployeeSerializer : IBinarySerializer
{
    public void WriteBinary(object obj, IBinaryWriter writer)
    {
        var employee = (Employee)obj;

        writer.WriteGuid("employeeId", employee.EmployeeId );
        writer.WriteString("name", employee.Name);
        writer.WriteObject("address", employee.Address);
    }

    public void ReadBinary(object obj, IBinaryReader reader)
    {
        var employee = (employee)obj;

        employee.EmployeeId  = reader.ReadObject<Guid>("employeeId");
        employee.Name = reader.ReadString("name");
        employee.Address = reader.ReadObject<Address>("address");
    }
}


public sealed class AddressSerializer : IBinarySerializer
{
    public void WriteBinary(object obj, IBinaryWriter writer)
    {
        var address = (Address)obj;

        writer.WriteString("street", address.Street);
        writer.WriteString("zip", address.Zip);
    }

    public void ReadBinary(object obj, IBinaryReader reader)
    {
        var address = (Address)obj;

        address.Street = reader.ReadString("street");
        address.Zip = reader.ReadString("zip");
    }
}
 

Ответ №1:

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

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

Комментарии:

1. Спасибо за ответ, потому что мои модели немного сложны, включая вложенные объекты и массивы, поэтому мы должны определить в обоих местах, верно?

2. Я бы сказал, что да. Хотя это может зависеть от конкретного случая использования. Учтите следующее: как только вы захотите сохранить свою модель в кэше, сначала данные необходимо преобразовать в некоторый двоичный формат, отправить на соответствующий серверный узел (определяемый ключом кэша), а затем поместить на страницу данных внутри дерева B внизу. Как только вы прочитаете запись, ее необходимо сначала поместить в память страницы узла, а затем передать вызывающему для десериализации. Если это клиент, то нет необходимости в нескольких сериализациях, и сервер должен просто повторно отправить эти данные как есть.