Ignite架构

1.Ignite Virtual Memory（Ignite虚拟内存）

1.1 概述

从2.0版本开始，Apache ignite引入了一种新的堆外存储架构。
新的内存架构有以下好处:
>可预测的内存消耗.您可以将一组内存分配给一个Apache ignite节点进程，并以特定的ignite缓存来安排数据集，跨越像总初始值或者回收策略等
特性不同的的内存区域（regions）。
>自动内存碎片整理。Apache ignite尽可能高效地使用所有可用内存，并在后台执行碎片化例程，而不会影响应用程序的性能
>没有了由Apache ignite平台架构而引起的STOP-THE-WORLD（STW）垃圾回收的暂停。应用程序的代码是STW GC暂停的惟一可能来源。
>通过Apache ignite SQL引擎极大地提高了性能和内存使用率
>透明的交换。内存页可以被映射到一个memory-mapped的文件，将相关的活动转移到底层操作系统。
>与文件系统集成的能力，以便在磁盘上持久保存内存页，以实现持久性，并创建集群范围的快照(备份)

1.2 Ignite Virtual Memory（Ignite虚拟内存）

ignite虚拟内存是一种可管理的基于堆外的内存架构，它被分割成固定大小的页面。让我们来看看下面的图片，并尝试更多地了解这个内存架构。

1.2.1 Memory Regions（内存区域）

一个单独的Apache ignite节点的全部虚拟内存,可以由一个或者多个内存区域所构成。一个内存区域就是一个由memory policy（下面会讲到的）配置了的可扩张的逻辑的区域。这个内存区域的大小可以各不相同，回收策略和其他的参数解释会在下面讲

1.2.2 Memory Segment（内存段）

每个内存区域都以初始大小开始，并且有一个可以最大扩展到的最大内存值。
内存区域（Memory Regions）扩展到其最大边界，分配连续的内存段（Memory Segment）。默认情况下，内存区域（Memory Regions）的最大大小设置为系统上可用物理内存的80%。
默认的最大大小：
    如果内存区域的最大大小没有显式地设置(通过org.apache.ignite.configuration.MemoryPolicyConfiguration.setMaxSize())，那
    么它可以占到您机器上可用的RAM的80%。
内存段是从操作系统中获取的一个物理连续字节数组。块被分为固定大小的页面。有几种类型的页面可以驻留在片段中，如下图所示。

1.2.3 Data Page（数据页）

一个数据页存储的是你从应用端put进Apache ignite缓存中的缓存条目。（在上面的图片中，数据页是绿色的）
通常的，一个单独的数据页保留着着多个键值条目，以便尽可能高效地使用内存，避免内存碎片化。当一个key-value条目被添加进缓存时，这个虚拟内存就会查找一个可以装载得了整个条目的数据页，并将条目放进去。然而，如果一个条目的总大小超过了通过MemoryConfiguration.setPageSize(..)所设置的页大小，那么，这个条目将占据多个数据页。
Entry Ownership by Data Page：
    键值条目可能不会一直被绑定到特定的页面。例如，如果在更新条目时，条目扩展，并且它的当前页面不再适合它，那么虚拟内存将搜索一个新的数
    据页，它有足够的空间来执行更新的条目，并将会移动条目。

1.2.4 B+ Tree and Index Page

在应用程序中定义和使用的SQL索引以B +树数据结构的形式进行排列和维护。对于在SQL模式中声明的每个唯一索引，Apache ignite实例化并管理一个专用的B +树实例。

Hash Index:
    缓存条目的键也从B +树数据结构中引用。它们是由散列码值排序的。

正如上面的图所示，整个B+树的目的是连接和排序那些被分配并存储在虚拟内存的随机物理位置上的索引页。在内部，索引页包含定位索引值所需的所有信息，指向缓存条目在数据页中的偏移量的引用，以及指向其他索引页来的引用以方便的来遍历树(索引页在上图中是紫色的)。
B +树元页面需要到特定的B +树的根和它的层，以有效执行范围查询,例如，当myCache.get(keyA)操作发生的时候，它将在Apache ignite节点上触发以下执行流:
    1.Apache Ignite将查找myCache所属的内存区域
    2.在该内存区域内，会定位到一个保存了myCache的所有键的B+树元页。
    3.将计算keyA的哈希码，并在B +树中搜索键所属的索引页。
    4.如果没有找到对应的索引页，则意味着在myCache中不存在键值对，Apache ignite将返回null作为myCache.get(keyA)操作的结果。
    5.如果索引页面存在，那么它将包含找到缓存条目keyA的数据页所需要的所有信息
    6.从数据也获得缓存条目，并返回给你的应用。

12.2.5 Free Lists Metadata and Structure

前一节中解释说的执行流，是当你在程序中从内存查找某一个值，缓存时如何在内存页中查找。但是，当你操作myCache.put(keyA, valueA)，内存页是怎么来存储的呢？
在这种情况下，虚拟内存依赖于空闲列表数据结构。基本上，一个空闲列表是一个双链表，它将引用存储在几乎相等的空闲空间的内存页上。例如，有一个空闲的列表，它存储了高达75%的空闲空间的所有数据页和一个跟踪索引页的列表，这些页面的容量为25%。数据和索引页在单独的自由列表中被跟踪。

记住这一点，在某一个节点，该节点可能是一个主节点也可能是一个备份节点，myCache.put(keyA, valueA)的操作的执行流，，或多或少如下:
    1.Apache ignite将会查找myCahce这个缓存对象所属于的内存区域。
    2.在该内存区域内，会定位到一个保存了myCache的所有键的B+树元页。
    3.将计算keyA的哈希码，并在B +树中搜索键所属的索引页。
    4.如果没有找到索引页，则根据索引大小从一个空闲列表中请求它。一个有针对性的空闲列表将通过一个空闲的列表元页面找到。一旦提供了索引页，它将被添加到B +树层次结构中。
    5.如果在这个索引页中没有指向数据页的索引，那么会依据缓存条目的大小，所依赖的空闲列表将给出一个数据页。将在索引页中添加对数据页的引用。
    6.将缓存条目添加到数据页中

1.2.6 Configuration Parameters

改变全局虚拟内存设置，如页大小，使用传递给IgniteConfiguration.setMemoryConfiguration(...)方法的参数：org.apache.ignite.configuration.MemoryConfiguration对象。下面你可以看到所有可用的参数:

参数名	描述	默认值
setPageSize(…)	设置默认的页的大小	2 KB
setDefaultMemoryPolicySize(…)	设置自动创建的默认内存区域的大小。如果不设置得很娿，就使用武力内存的80%	80%
setDefaultMemoryPolicyName(…)	设置默认内存策略的名称。默认情况下，每个缓存都绑定到一个实例化该策略的内存区域。参考内存策略部分了解更多关于内存策略的信息。	default
setMemoryPolicies(…)	设置集群中可用的所有内存策略的参考内存策略部分了解更多关于内存策略的信息。	一个空数组。用于创建默认区域的配置不存储在那里。
setSystemCacheInitialSize(…)	设置用于系统缓存的内存区域的初始大小。	40M
setSystemCacheMaxSize(…)	设置用于系统缓存的内存区域的最大大小。由于内部数据结构的开销，总大小不应该小于10 MB	100 MB
setConcurrencyLevel(…)	设置Apache中并发段的数量，点燃内部页面映射表	可用cpu的总数乘以4

下面的示例展示了如何使用MemoryConfiguration来更改页面大小和并发级别:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="memoryConfiguration">
        <bean class="org.apache.ignite.configuration.MemoryConfiguration">
            <!-- Setting the concurrency level -->
            <property name="concurrencyLevel" value="4"/>

            <!-- Setting the page size to 4 KB -->
            <property name="pageSize" value="4096"/>
        </bean>
    </property>

  <!--- Additional settings ---->
</bean>

// Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();

// Page memory configuration.
MemoryConfiguration memCfg = new MemoryConfiguration();

// Altering the concurrency level.
memCfg.setConcurrencyLevel(4);

// Changing the page size to 4 KB.
memCfg.setPageSize(4096);

// Applying the new page memory configuration.
cfg.setMemoryConfiguration(memCfg);

1.2 Memory Policies（内存策略）

默认情况下，虚拟内存启动一个可扩展的内存区域，可以占用本地机器上80%的可用内存。但是，有一种方法可以根据内存策略的API定义，设定不同参数和自定义行为，来定义多个内存区域。
内存策略是一组配置参数，暴露在org.apache.ignite.configuration.MemoryPolicyConfiguration类中，例如初始和最大区域大小、驱逐策略、交换文件等。
例如，要配置一个500 MB的内存区域，并启用的数据页回收机制，我们需要定义如下的内存策略:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
   <!-- Virtual Memory configuration -->   
   <property name="memoryConfiguration">
      <bean class="org.apache.ignite.configuration.MemoryConfiguration">
        <!-- Defining a custom memory policy. -->
        <property name="memoryPolicies">
          <list>
            <!-- 500 MB total size and RANDOM_2_LRU eviction algorithm. -->
            <bean class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
              <property name="name" value="500MB_Region_Eviction"/>
              <!-- 100 MB initial size. -->
              <property name="initialSize" value="#{100 * 1024 * 1024}"/>
              <!-- 500 MB maximum size. -->
              <property name="maxSize" value="#{500 * 1024 * 1024}"/>
              <!-- Enabling data pages eviction. -->
              <property name="pageEvictionMode" value="RANDOM_2_LRU"/>
            </bean>
          </list>
        </property>
      </bean>
   </property>

  <!-- The rest of the configuration. -->
  <!-- ....... -->
</bean>

// Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();

// Virtual Memory configuration.
MemoryConfiguration memCfg = new MemoryConfiguration();

// Creating a custom memory policy for a new memory region.
MemoryPolicyConfiguration plCfg = new MemoryPolicyConfiguration();

// Policy/region name.
plCfg.setName("500MB_Region_Eviction");

// Setting initial size.
plCfg.setInitialSize(100L * 1024 * 1024);

// Setting maximum size.
plCfg.setMaxSize(500L * 1024 * 1024);

// Setting data pages eviction algorithm.
plCfg.setPageEvictionMode(DataPageEvictionMode.RANDOM_2_LRU);

// Applying the memory policy.
memCfg.setMemoryPolicies(plCfg);

// Applying the new page memory configuration.
cfg.setMemoryConfiguration(memCfg);

Apache ignite缓存可以映射到这个内存区域(参见下面的配置示例)。为了实现这个目标，必须将策略的名称作为参数传递给org.apache.ignite.configuration.CacheConfiguration.setMemoryPolicyName(...)方法:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!-- Virtual Memory and other configuration parameters. -->
    <!-- ....... -->

    <property name="cacheConfiguration">
       <list>
           <!-- Cache that is mapped to non-default memory region. -->
           <bean class="org.apache.ignite.configuration.CacheConfiguration">
              <!--
                   Setting a memory policy name to bind to a specific region.
               -->
               <property name="memoryPolicyName" value="500MB_Region_Eviction"/>
               <!-- Cache unique name. -->
               <property name="name" value="SampleCache"/>

               <!-- Additional cache configuration parameters -->
           </bean>
       </list>
    </property>

    <!-- The rest of the configuration. -->
    <!-- ....... -->
</bean>  

// Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();

// Virtual Memory configuration and the rest of the configuration.
// ....

// Creating a cache configuration.
CacheConfiguration cacheCfg = new CacheConfiguration();

// Setting a memory policy name to bind to a specific memory region.
cacheCfg.setMemoryPolicyName("500MB_Region_Eviction");

// Setting the cache name.
cacheCfg.setName("SampleCache");

// Applying the cache configuration.
cfg.setCacheConfiguration(cacheCfg);

一旦一个Apache ignite集群以这个配置启动,页面内存将分配100 MB区域，并最高可增长到500 MB。新区域将与默认内存区域共存的所有数据以及索引,上面的例子忽略了的是，SampleCache 这个缓存将会居住在这个区域里。除非您使用上面所示的技术将它们映射到另一个区域，否则在部署中可能有的其他缓存将绑定到默认内存区域。
如果总体内存使用超过了最大大小参数，那么将抛出内存异常。为了避免这种情况，使用下面描述的回收算法或将大小设置为更大的值。

PS:Changing Default Memory Policy
默认的内存区域是由org.apache.ignite.configuration.MemoryConfiguration.createDefaultPolicyConfig()方法所准备的默认内存策略的参数实例化的。如果您需要更改一些参数，遵循下面的步骤：
    1.使用自定义名称和参数创建新的内存策略
    2.将策略的猫名字传递给org.apache.ignite.configuration.MemoryConfiguration. setDefaultMemoryPolicyName(...)方法。
Configuration Parameters（参数配置）：

参数名	描述	默认值
setName(…)	唯一的内存策略名	必要参数
setInitialSize(…)	设置由该内存策略定义的内存区域的初始大小。当使用的内存大小超过这个值时，将分配新的内存块，直到达到最大尺寸。	256M
setMaxSize(…)	设置由该内存策略定义的内存区域的最大大小。由于内部数据结构的开销，总大小不应该小于10 MB。如果整个内存使用超出这个参数，将抛出一个内存异常。为了避免使用强制驱逐算法，或者将该参数设置为更大的值。	RAM 80%
setSwapFilePath(…)	到memory-mapped文件的路径，由这个内存策略定义的内存区域将会被映射到这里。有了这个设置的路径，就可以允许依赖这个区域所在的底层操作系统的交换功能	默认情况下禁用。
setPageEvictionMode(…)	，回收算法可供使用的数据页的设置之一。请参阅回收政策为更多的细节。	默认情况下禁用
setEvictionThreshold(…)	内存分页回收启动的阈值。例如，如果阈值为0.9，这意味着只有在90%的内存区域(由该策略定义)之后，页内存才会启动回收。	0.9
setEmptyPagesPoolSize(…)	指定用于此内存策略的重用列表中出现的最少空白页。这个参数确保Apache ignite在一个(键值)对的大小略大于页大小的1/2时能够成功地回收驱逐旧的数据条目。 如果缓存可以包含非常大的条目，则增加此参数（这个池中页面的总大小应该足以包含最大的缓存条目。）	100
setMetricsEnabled(…)	为该区域启用内存指标聚合。有关更多细节，请参考内存和缓存指标。	false

1.3 Eviction Modes （回收驱逐模型）、

内存策略允许为保存key-value的数据页设置不同的回收模型。要了解更多关于可用算法的信息，请参阅本文档https://apacheignite.readme.io/docs/evictions

1.4 On-heap Caching（堆缓存）

ignite虚拟哦缓存时一个堆外缓存，它在java的堆之外为内存区域分配内存，以达到缓存条目的目的。但是，您可以通过设置org.apache.ignite.configuration.CacheConfiguration.setOnheapCacheEnabled(...)为true来启用对缓存条目的堆缓存。
堆缓存适用于在使用二进制形式的缓存条目或调用缓存条目的反序列化的服务器节点做大量的缓存读取的操作的情景。例如，当分布式计算或已部署的服务从缓存中获取一些数据进行进一步处理时，可能会出现这种情况。
堆缓存大小：
    为了管理堆的缓存大小并避免其持续的增长，请确保启用了一个基于回收策略的可用缓存项（参考回收策略那一章）。

2.Binary Marshaller

2.1 概述

从1.5开始，ignite新添加了一个存储数据的新概念，叫做BinaryObjects。这里有一些它相对于传统的序列化的一些优点：
1.它使您能够从序列化形式的对象中读取任意字段，而不需要进行反序列化的。这种能力完全移除缓存键和值类在类路径中的服务器节点上部署的要求。
2.它允许您从相同类型的对象中添加和删除字段。由于服务器节点没有模型类定义，这个功能就可以允许你动态的修改一个对象的结构。并且甚至可以允许具有不同版本的类定义的多个客户机同时存在。
3.它使您能够根据类型名称构造新对象，而不需要具有类定义，因此允许动态类型创建。、
二进制对象只有在使用默认的二进制编组时才可以使用（不会显式地设置其他的marshaller配置）
PS:Restrictions:
下面有几个由BinaryObject格式的实现所隐含的几个限制条件：
    >在内部，ignite并不写下字段和类型的名字，但是使用小写的名称散列来标识字段或类型。这意味着不允许使用相同名称散列的字段或类型。尽管串行化不会在散列冲突的情况下工作，但是ignite提供了一种解决配置级别上的冲突的方法。
    >出于同样的原因，BinaryObject格式不允许在类层次结构的不同级别上用相同的字段名。
    >Externalizable 接口默认情况下被忽略。如果使用了BinaryObject格式，那么可外部化类将以与序列化的方式相同的方式编写，而不使用writeExternal()和readExternal()方法 。如果出于某种原因，这对您不适用，您应该为类实现Binarylizable接口，插入自定义的BinarySerializer或切换到OptimizedMarshaller。

IgniteBinary 是可以从ignite实例中获取到的，包含与二进制对象一起工作的所有必要方法。

2.2 二进制对象配置

在绝大多数用例中，不需要另外配置二进制对象。
然而，如果你需要重写（override）默认的类型和字段id计算，或者插入BinarySerializer，那么就需要在IgniteConfiguration配置中定义BinaryConfiguration 配置对象。这个对象允许指定一个全局名称映射器，一个全局ID映射器，以及一个全局二进制序列化器以及每个类型的映射器和序列化器。通配符支持每个类型的配置，在这种情况下，提供的配置将适用于所有匹配类型名称模板的类型。

<bean id="ignite.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">

  <property name="binaryConfiguration">
    <bean class="org.apache.ignite.configuration.BinaryConfiguration">

      <property name="nameMapper" ref="globalNameMapper"/>
      <property name="idMapper" ref="globalIdMapper"/>

      <property name="typeConfigurations">
        <list>
          <bean class="org.apache.ignite.binary.BinaryTypeConfiguration">
            <property name="typeName" value="org.apache.ignite.examples.*"/>
            <property name="serializer" ref="exampleSerializer"/>
          </bean>
        </list>
      </property>
    </bean>
  </property>
...

2.2.1 BinaryObject缓存API

默认情况下，ignite以反序列化值来工作的，因为他是最常用的用例。要启用BinaryObject处理,用户需要使用withKeepBinary()方法获得IgniteCache实例。启用时，这个标志将确保在可能的情况下，从缓存返回的对象将处于BinaryObject格式。传递给EntryProcessor 和CacheInterceptor的值也会同样如此。
Platform Types ：
    注意，在启用withKeepBinary()标志时，并不是所有类型都将表示为BinaryObject。有一组“平台”类型，包括原始类型、字符串、UUID、日期、时间戳、BigDecimal、集合、映射和它的数组，这些都不会被表示为BinaryObject。
    请注意，在下面的例子中，key类型的整数没有改变，因为它是一个平台类型。

// Create a regular Person object and put it to the cache.
Person person = buildPerson(personId);
ignite.cache("myCache").put(personId, person);

// Get an instance of binary-enabled cache.
IgniteCache<Integer, BinaryObject> binaryCache = ignite.cache("myCache").withKeepBinary();

// Get the above person object in the BinaryObject format.
BinaryObject binaryPerson = binaryCache.get(personId);

2.2.2 使用BinaryObjectBuilder修改二进制对象

BinaryObject实例是不可变的。为了更新字段和创建新的BinaryObject，必须使用binaryobjectbuilder实例。
BinaryObjectBuilder 对象实例可以从IgniteBinary外观对象中获取。构建器可以使用类型名称创建,在这种情况下，返回的生成器将不包含字段，或者也可以使用现有的BinaryObject来创建，在这种情况下，返回的生成器将从给定的BinaryObject中复制所有字段。
另一种获取BinaryObjectBuilder实例的方法是在一个BinaryObject的现有实例上调用toBuilder()。这还将将BinaryObject中的所有数据复制到创建的生成器中。
BinaryObjectBuilder和散列码：
    请注意，如果构造的BinaryObject将用作缓存的键，那么将一个适当的散列代码设置进BinaryObjectBuilder是很重要的，因为构建器不会自动
    计算散列代码，而返回的BinaryObject将没有其他的哈希码。

下面是使用 BinaryObject API 来处理服务器节点上的数据，而无需在服务器上部署的用户类和没有实际数据反序列化的示例。

//BinaryObject Inside EntryProcessor
// The EntryProcessor is to be executed for this key.
int key = 101;

cache.<Integer, BinaryObject>withKeepBinary().invoke(
  key, new CacheEntryProcessor<Integer, BinaryObject, Object>() {
    public Object process(MutableEntry<Integer, BinaryObject> entry,
                          Object... objects) throws EntryProcessorException {
            // Create builder from the old value.
        BinaryObjectBuilder bldr = entry.getValue().toBuilder();

        //Update the field in the builder.
        bldr.setField("name", "Ignite");

        // Set new value to the entry.
        entry.setValue(bldr.build());

        return null;
     }
  });

2.3 BinaryObject Type Metadata

正如上面提到的，二进制对象结构在运行时可能会发生改变，因此，获取存储在缓存中的特定类型的信息可能也很有用，比如字段名、字段类型名和关联字段名。ignite通过BinaryType接口来使这个需求变得简单。
这个接口还引入了一个名为BinaryField的字段getter的更快版本.这个概念类似于java反射，它允许缓存关于在BinaryField实例中读取的字段的某些信息，这在从大量二进制对象的大型集合中读取相同字段时非常有用.

//BinaryField Example
Collection<BinaryObject> persons = getPersons();

BinaryField salary = null;

double total = 0;
int cnt = 0;

for (BinaryObject person : persons) {
    if (salary == null)
        salary = person.type().field("salary");

    total += salary.value(person);
    cnt++;
}

double avg = total / cnt;

2.3.1 BinaryObject and CacheStore

在缓存API上设置withKeepBinary()不会影响将用户对象传递给CacheStore的方式。这是有意的，因为在大多数情况下，单个的CacheStore实现要么使用反序列化的类，要么使用BinaryObject表示。要控制将对象传递给存储的方式，应该使用CacheConfiguration 的storeKeepBinary 标志。当此标志被设置为false时，反序列化值将被传递到存储，否则将使用BinaryObject表示。
下面是一个与BinaryObject工作的商店的伪代码实现:

//Binary CacheStore Implementation
public class CacheExampleBinaryStore extends CacheStoreAdapter<Integer, BinaryObject> {
    @IgniteInstanceResource
    private Ignite ignite;

    /** {@inheritDoc} */
    @Override public BinaryObject load(Integer key) {
        IgniteBinary binary = ignite.binary();

        List<?> rs = loadRow(key);

        BinaryObjectBuilder bldr = binary.builder("Person");

        for (int i = 0; i < rs.size(); i++)
            bldr.setField(name(i), rs.get(i));

        return bldr.build();
    }

    /** {@inheritDoc} */
    @Override public void write(Cache.Entry<? extends Integer, ? extends BinaryObject> entry) {
        BinaryObject obj = entry.getValue();

        BinaryType type = obj.type();

        Collection<String> fields = type.fieldNames();

        List<Object> row = new ArrayList<>(fields.size());

        for (String fieldName : fields)
            row.add(obj.field(fieldName));

        saveRow(entry.getKey(), row);
    }
}

2.4 二进制名称映射器和二进制ID映射器

在内部，ignite从不为字段或类型名称写完整的字符串。相反，出于性能原因，点火为类型和字段名写入整数哈希码。已经测试过，对于类型名称或同一类型中的字段名称的散列代码冲突实际上是不存在的，为了获得性能，使用哈希代码是安全的。对于不同类型或字段的散列代码实际发生碰撞的情况，BinaryNameMapper和BinaryIdMapper允许覆盖类型和字段名的自动生成的散列代码id。
BinaryNameMapper --将类型/类和字段名称映射到不同的名称。
BinaryIdMapper ----由给定的BinaryNameMapper的类型和字段名映射到ID，以在ignite内部使用。
ignite提供了下列开箱即用的mappers实现:
    1.BinaryBasicNameMapper ---他是一个基础的BinaryNameMapper 的实现，根据使用的setSimpleName属性，返回一个完整或简单的给定类名称。
    2.BinaryBasicIdMapper ---他是BinaryIdMapper的一个基础的实现。他有一个setLowerCase(boolean isLowerCase）来配置属性。如果一个属性被设置了false，那么将返回一个由给定的类型或者属性名的哈希码。如果这个属性设置成true，那么将返回一个给定的类型或者属性名字的小写形式的哈希码。
如果您只使用Java客户端，并且不指定BinaryConfiguration中的映射器，那么将使用BinaryBasicNameMapper，并且将simpleName属性设置为false，而BinaryBasicIdMapper和lowerCase 属性将被设置为true。
你如果使用C#或者c++客户端，不要在BinaryConfiguration中指定映射器，那么ignite江湖使用BinaryBasicNameMapper，并且将simpleName属性设置为true，而BinaryBasicIdMapper和lowerCase 属性将被设置为true。
默认情况下，如果使用Java，就不需要配置任何东西。.net或c++。当需要平台互操作性时，需要配置一个复杂的名称转换。