Apache-Ignite-2.0.0-中文开发手册

10.Ignite架构

10.1.二进制编组器

10.1.1.基本概念

从1.5版本开始，Ignite引入了一个在缓存中存储数据的新概念，名为二进制对象，这个新的序列化格式提供了若干个优势：

• 他可以从一个对象的序列化形式中读取一个任意的属性，而不需要将该对象完整地反序列化，这个功能完全删除了将缓存的键和值类部署到服务端节点类路径的必要性；
• 他可以为同一个类型的对象增加和删除属性，给定的服务端节点不需要有模型类的定义，这个功能允许动态改变对象的结构，甚至允许多个客户端持有类定义的不同版本，他们是共存的；
• 他可以根据类型名构造一个新的对象，根本不需要类定义，因此允许动态类型创建；

二进制对象只可以用于使用默认的二进制编组器时（即没有在配置中显式地设置其他的编组器）

限制
BinaryObject格式实现也带来了若干个限制：
1. 在内部Ignite不会写属性以及类型的名字，但是使用一个小写的名字哈希来标示一个属性或者类型，这意味着属性或者类型不能有同样的名字哈希。即使序列化不会在哈希冲突的情况下工作，但Ignite在配置级别提供了一种方法来解决此冲突；
2.同样的原因，BinaryObject格式在类的不同层次上也不允许有同样的属性名；
3.默认会忽略Externalizable接口。如果使用了BinaryObject格式，Externalizable类型会与Serializable类型是同样的处理方式，没有writeExternal()和readExternal()方法。如果由于某些原因这样不行，需要实现Binarylizable接口，加入一个自定义BinarySerializer或者切换到OptimizedMarshaller。

IgniteBinary入口，可以从Ignite的实例获得，包含了操作二进制对象的所有必要的方法。

10.1.2.配置二进制对象

在绝大多数情况下不需要额外地配置二进制对象。
但是，如果需要覆写默认的类型和属性ID计算或者加入BinarySerializer，可以为IgniteConfiguration定义一个BinaryConfiguration对象，这个对象除了为每个类型指定映射以及序列化器之外还可以指定一个全局的Name映射、一个全局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>
...

10.1.4.BinaryObject缓存API

Ignite默认使用反序列化值作为最常见的使用场景，要启用BinaryObject处理，需要获得一个IgniteCache的实例然后使用withKeepBinary()方法。启用之后，如果可能，这个标志会确保从缓存返回的对象都是BinaryObject格式的。将值传递给EntryProcessor和CacheInterceptor也是同样的处理。

平台类型
注意当通过withKeepBinary()方法启用BinaryObject处理时并不是所有的对象都会表示为BinaryObject，会有一系列的平台类型，包括基本类型，String，UUID，Date，Timestamp，BigDecimal，Collections，Maps和Arrays，他们不会被表示为BinaryObject。
注意在下面的示例中，键类型为Integer，他是不会被修改，因为他是平台类型。

获取BinaryObject：

// 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);

10.1.5.使用BinaryObjectBuilder修改二进制对象

BinaryObject实例是不能修改的，要更新属性或者创建新的BinaryObject，必须使用BinaryObjectBuilder的实例。
BinaryObjectBuilder的实例可以通过IgniteBinary入口获得。他可以使用类型名创建，这时返回的对象不包含任何属性，或者他也可以通过一个已有的BinaryObject创建，这时返回的对象会包含从给定的BinaryObject中拷贝的所有属性。
获取BinaryObjectBuilder实例的另外一个方式是调用已有BinaryObject实例的toBuilder()方法，这种方式创建的对象也会从BinaryObject中拷贝所有的数据。

BinaryObjectBuilder和哈希值
注意如果构造的BinaryObject用做缓存键，很重要的是要为BinaryObjectBuilder设置正确的哈希值，因为构造器不会自动计算哈希值，然后导致返回的BinaryObject哈希值为0。

下面是一个使用BinaryObjectAPI来处理服务端节点的数据而不需要将程序部署到服务端以及不需要实际的数据反序列化的示例：
EntryProcessor内的BinaryObject：

cache.<Integer, BinaryObject>withKeepBinary().invoke(
    new CacheEntryProcessor<Integer, BinaryObject, Void>() {
        @Override Void process(
            MutableEntry<Integer, BinaryObject> entry, Object... args) {
            // 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;
        }
    });

10.1.6.BinaryObject类型元数据

像上面描述的那样，二进制对象结构可以在运行时进行修改，因此获取一个存储在缓存中的一个特定类型的信息也可能是有用的，比如属性名，属性类型，属性类型名，关系属性名，Ignite通过BinaryType接口满足这样的需求。
这个接口还引入了一个属性getter的更快的版本，叫做BinaryField。这个概念类似于Java的反射，可以缓存BinaryField实例中读取的属性的特定信息，他有助于从一个很大的二进制对象集合中读取同一个属性。

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;

10.1.7.BinaryObject和CacheStore

在缓存API上调用withKeepBinary()方法对于将用户对象传入CacheStore的方式不起作用，这么做是故意的，因为大多数情况下单个CacheStore实现要么使用反序列化类，要么使用BinaryObject表示。要控制对象传入Store的方式，需要使用CacheConfiguration的storeKeepBinary标志，当该标志设置为false时，会将反序列化值传入Store，否则会使用BinaryObject表示。
下面是一个使用BinaryObject的Store的伪代码实现的示例：

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);
    }
}

10.1.8.二进制Name映射器和二进制ID映射器

在内部，Ignite不会写属性或者类型名字的完整字符串，而是因为性能的原因，为类型或者属性名写一个整型哈希值作为替代。经过测试，在类型相同时，属性名或者类型名的哈希值冲突实际上是不存在的，为了获得性能，使用哈希值是安全的。对于当不同的类型或者属性确实冲突的场合，BinaryNameMapper和BinaryIdMapper可以为该类型或者属性名覆写自动生成的哈希值。
BinaryNameMapper - 映射类型/类和属性名到不同的名字；
BinaryIdMapper - 映射从BinaryNameMapper来的类型和属性名到ID，以便于Ignite内部使用。
Ignite提供了下面的开箱即用的映射器实现：

• BinaryBasicNameMapper：BinaryNameMapper的一个基本实现，对于一个给定的类，根据使用的setSimpleName(boolean useSimpleName)属性值，会返回一个完整或者简单的名字；
• BinaryBasicIdMapper：BinaryIdMapper的一个基本实现，他有一个setLowerCase(boolean isLowerCase)配置属性，如果属性设置为false，那么会返回一个给定类型或者属性名的哈希值，如果设置为true，会返回一个给定类型或者属性名的小写形式的哈希值。

如果仅仅使用Java客户端并且在BinaryConfiguration中没有指定映射器，那么Ignite会使用BinaryBasicNameMapper并且simpleName属性会被设置为false，使用BinaryBasicIdMapper并且lowerCase属性会被设置为true。
如果使用了.Net或者C++客户端并且在BinaryConfiguration中没有指定映射器，那么Ignite会使用BinaryBasicNameMapper并且simpleName属性会被设置为true，使用BinaryBasicIdMapper并且lowerCase属性会被设置为true。
如果使用Java、.Net或者C++，默认是不需要任何配置的，只有当需要平台协同、名字转换复杂的情况下，才需要配置映射器。

10.2.Ignite虚拟内存

10.2.1.摘要

从2.0版本开始，Ignite推出了一个新的堆外内存架构。

新的内存架构有如下的好处：

• 可预测的内存消耗：可以为Ignite节点进程分配一定量的内存，然后为跨越有不同特性（比如总容量）内存区域的、特定的缓存分配数据集。
• 自动化清理内存碎片：Ignite会尽可能高效地使用所有的可用内存，然后在后台执行清理内存碎片的程序，前提是不影响应用的性能。
• Ignite的平台架构不会触发垃圾回收（GC）导致的暂停，应用的代码是导致GC暂停的唯一可能源头。
• 极大地改进了Ignite SQL引擎的性能和内存使用。
• 透明交换：页面内存可以映射到一个内存映射文件，用于将和交换有关的活动卸载到底层操作系统。
• 能够与文件系统集成，为了持久化将内存页面持久化到磁盘上，然后创建集群范围的快照（备份）。

10.2.2.页面内存

页面内存是一个可管理的基于堆外的的内存架构，它将内存拆分为固定大小的页面，下面看一下架构图，然后理解有关这一架构的更多信息。

内存区
每个Ignite节点的整个页面内存可以由一个或者多个内存区组成，一个内存区是通过内存策略配置的逻辑可扩展区域，这个区域大小可变，退出策略以及其他的参数在下面的内存策略中会详述。
内存块
每个内存区都开始于初始值，然后有一个可增长的最大值。这个区域扩展至其最大值的过程中，都会被分配连续的内存块。内存区的最大值默认为系统可用物理内存的80%。

默认最大值
如果内存区的最大值没有显式地配置（通过org.apache.ignite.configuration.MemoryPolicyConfiguration.setMaxSize()），那么它会使用机器可用RAM的80%。

一个内存块是从操作系统获得的物理连续字节数组，这个块会被分为固定大小的页面，该块中可以驻留若干种不同类型的页面：
数据页面
数据页面存储的是从应用端插入Ignite缓存中的缓存条目（数据页面在上图中标注为绿色）。
通常，一个数据页面持有多个键-值条目，以更高效地利用内存避免内存碎片。当新的键-值条目加入缓存时，页面内存机制会查找适合该条目的页面然后加入里面。但是，当条目的总大小达到通过MemoryConfiguration.setPageSize(..)参数配置的页面大小时，该条目会占据多于一个数据页面。

数据页面对于条目的所有权
一个键值条目不会一直绑定到一个特定的页面，比如在一次更新过程中，条目占用空间变大，然后它的当前页面不再适合它，然后页面内存会查找一个新的数据页面以能够容纳更新后的条目并且将其移动到那里。

B+树和索引页面
应用定义和使用的SQL索引是以B+树数据结构的形式进行维护的。对于一个SQL模式中声明的每个唯一索引，Ignite会实例化并且管理一个专用的B+树实例。

哈希索引
B+树数据结构也会引用缓存条目的键，它们通过哈希值进行排序。

如上图所示，整个B+树的目的就是链接和排序索引页面，这些索引页面是在页面内存的随机物理空间分配和存储的。
从内部来说，索引页面包括了定位索引值、索引指向的缓存条目在数据页面中的偏移量、还有到其他索引页面的引用（用来遍历树）等所有必要的信息，索引页面在上图中标注为紫色。
B+树的元页面需要获得特定B+树的根和它的层次，以高效地执行范围查询。比如，当执行myCache.get(keyA)操作时，在一个节点上它会触发下面的操作流程：

1. Ignite会查找myCache属于那个内存区；
2. 在该内存区中，会定位持有myCache的键的B+树的元页面；
3. 会计算keyA的哈希值，然后在B+树中检索该键所属的索引页面；
4. 如果对应的索引页面没找到，那么意味着该键值对在myCache中不存在，然后Ignite会返回null作为myCache.get(keyA)操作的返回值；
5. 如果索引页面存在，那么它会包含找到缓存条目keyA所在的数据页面的所有必要信息；
6. 在数据页面找到缓存条目然后返回给应用。

空闲列表元数据和结构
前述章节的执行流程描述的是当应用希望获取缓存时在页面内存中如何检索缓存的条目。但是，当调用像myCache.put(keyA,valueA)这样的操作时，页面内存如何知道将一个新的条目放于何处呢？
在这个场景中，页面内存依赖的是空闲列表数据结构。基本上来说，空闲列表是一个双向链表，它存储了到大致相当于空闲空间的内存页面的引用。比如，有一个空闲列表，它存储了所有的数据页面，它占用了最多75%的空闲空间，还有一个列表来跟踪索引页面，它占用了剩余的25%的容量，数据和索引页面是由独立的空闲列表来跟踪的。
记住，在一个Ignite节点中myCache.put(keyA,valueA)操作的执行流程，对于一个条目来说可能是主，也可能是备节点，大体如下：

1. Ignite会找到myCache所属的内存区；
2. 在该内存区中，会定位持有myCache的键的B+树的元页面；
3. 会计算keyA的哈希值，然后在B+树中检索该键所属的索引页面；
4. 如果索引页面未找到，根据索引的大小，它会从空闲列表中申请，借助于空闲列表的元页面会找到一个目标空闲列表；
5. 如果索引页面中没有能放置该缓存条目的数据页面，根据总的缓存条目大小会从空闲列表中分配一个新的数据页面，然后在索引页面中添加到新数据页面的引用；
6. 该缓存条目会加入该数据页面。

配置参数
要调整全局页面内存的配置，比如页面大小，可以使用org.apache.ignite.configuration.MemoryConfiguration，它可以通过IgniteConfiguration.setMemoryConfiguration(...)方法传入，下面是所有可用的参数：

下面的示例代码显示通过MemoryConfiguration如何改变页面大小和并发层级：
XML：

<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>

Java:

// 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);

10.2.3.内存策略

页面内存默认会初始化一个单一的可扩展的内存区，这个内存区会使用本地主机最多80%的可用内存。但是，通过各种参数也可以定义多个内存区，然后通过内存策略API也可以对行为进行自定义。
内存策略是一组配置参数的集合，这些参数都是通过org.apache.ignite.configuration.MemoryPolicyConfiguration暴露的，比如初始和最大内存区大小，退出策略，交换文件等等。
比如，要配置一个500MB的内存区，开启数据页面退出，如下所示：
XML:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
   <!-- Page 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>

Java:

// Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();
// Page 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);

一个Ignite缓存可以被映射到该内存区（如下所示），怎么做呢，需要将策略的名字作为参数传递给org.apache.ignite.configuration.CacheConfiguration.setMemoryPolicyName(...)方法：
XML:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!-- Page 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>

Java：

// Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();
// Page 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);

当Ignite集群通过这个配置启动时，这个内存页面可以分配从100M~500M的内存区，这个新的内存区会和默认的内存区共存，在该示例中，SampleCache会驻留在该内存区，除非通过上面的方法明确指定，其他的缓存都会被映射到默认的内存区。
如果内存占用超过了参数配置的最大值，那么就会抛出内存溢出异常，要解决这个问题，可以使用下面描述的退出算法，或者将内存区最大值调大。

调整默认内存策略
通过org.apache.ignite.configuration.MemoryConfiguration.createDefaultPolicyConfig()方法会初始化默认的内存区。如果要调整部分参数，可以这样做：
1.通过自定义的名字和参数创建一个新的内存策略；
2.将策略的名字传递给org.apache.ignite.configuration.MemoryConfiguration. setDefaultMemoryPolicyName(...)方法。

这个示例代码显示了在集群中如何配置和使用多个内存区。
配置参数
org.apache.ignite.configuration.MemoryPolicyConfiguration支持如下的参数：

10.2.4.退出模式

内存策略可以为存储键值条目的数据页面配置各种退出模式，详细信息可以参照3.14.退出策略章节。

10.2.5.堆内缓存

页面内存是堆外的内存，它是在Java堆之外分配的内存区，然后将数据条目存储在其中。但是，通过将org.apache.ignite.configuration.CacheConfiguration.setOnheapCacheEnabled(...)配置为true为缓存条目开启堆内缓存。
当以二进制形式处理缓存条目或者调用缓存的反序列化时在服务端节点有大量的读操作，堆内缓存对这样的场景非常有用。比如，当一个分布式计算或者部署的服务为下一步处理从缓存中获取一些数据时，就会发生这样的情况。

堆内缓存大小
要管理堆内缓存的大小，避免其不断增长，一定要配置一个可用的基于缓存条目的退出策略。