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

2.集群化

2.1.集群化

Ignite具有非常先进的集群能力，包括逻辑集群组和自动发现。
Ignite节点之间会自动发现对方，这有助于必要时扩展集群，而不需要重启整个集群。开发者可以利用Ignite的混合云支持，允许公有云（比如AWS）和私有云之间建立连接,向他们提供两者的好处。

2.2.集群API

2.2.1.IgniteCluster

集群的功能是通过IgniteCluster接口提供的，可以像下面这样从Ignite中获得一个IgniteCluster的实例：

Ignite ignite = Ignition.ignite();
IgniteCluster cluster = ignite.cluster();

通过IgniteCluster接口可以：

• 启动和停止一个远程集群节点；
• 获取集群成员的列表；
• 创建逻辑集群组；

2.2.2.ClusterNode

ClusterNode接口具有非常简洁的API，他只处理集群中的几点，把他视为网络中的逻辑端点，他有一个唯一的ID，节点的元数据信息，静态属性集以及一些其他的参数。

2.2.3.集群节点属性

所有的集群节点在启动时都会自动地注册环境和系统的参数，把他们作为节点的属性，也可以通过配置添加自定义的节点属性。

<bean class="org.apache.ignite.IgniteConfiguration">
    ...
    <property name="userAttributes">
        <map>
            <entry key="ROLE" value="worker"/>
        </map>
    </property>
    ...
</bean>

下面的代码显示了如何获得设置了“worker”属性的节点：

ClusterGroup workers = ignite.cluster().forAttribute("ROLE", "worker");
Collection<ClusterNode> nodes = workers.nodes();

所有的节点属性都是通过ClusterNode.attribute("propertyName")方法获得的。

2.2.4.集群节点指标数据

Ignite自动收集所有集群节点的指标数据，指标数据是在后台收集的并且被集群节点之间的每一次心跳消息交换所更新。
节点的指标数据是通过ClusterMetrics接口体现的，他包括至少50种指标（注意，同样的指标也可以用于集群组）。
下面的例子显示了获取一些元数据信息，包括本地节点的平均CPU负载，已用堆大小：

// Local Ignite node.
ClusterNode localNode = cluster.localNode();
// Node metrics.
ClusterMetrics metrics = localNode.metrics();
// Get some metric values.
double cpuLoad = metrics.getCurrentCpuLoad();
long usedHeap = metrics.getHeapMemoryUsed();
int numberOfCores = metrics.getTotalCpus();
int activeJobs = metrics.getCurrentActiveJobs();

2.2.5.本地集群节点

本地集群节点是ClusterNode的一个实例，表示当前的Ignite节点。
下面的例子显示如何获得本地节点：

ClusterNode localNode = ignite.cluster().localNode();

2.3.集群组

ClusterGroup表示集群内节点的一个逻辑组。
从设计上讲，所有集群节点都是平等的，所以没有必要以一个特定的顺序启动任何节点，或者给他们赋予特定的规则。然而，Ignite可以因为一些应用的特殊需求而创建集群节点的逻辑组，比如，可能希望只在远程节点上部署一个服务，或者给部分worker节点赋予一个叫做‘worker’的规则来做作业的执行。

注意IgniteCluster接口也是一个集群组，只不过包括集群内的所有节点。

可以限制作业执行、服务部署、消息、事件以及其他任务只在部分集群组内执行，比如，下面这个例子只把作业广播到远程节点（除了本地节点）：
Java8：

final Ignite ignite = Ignition.ignite();
IgniteCluster cluster = ignite.cluster();
// Get compute instance which will only execute
// over remote nodes, i.e. not this node.
IgniteCompute compute = ignite.compute(cluster.forRemotes());
// Broadcast to all remote nodes and print the ID of the node 
// on which this closure is executing.
compute.broadcast(() -> System.out.println("Hello Node: " + ignite.cluster().localNode().id());

Java7：

final Ignite ignite = Ignition.ignite();
IgniteCluster cluster = ignite.cluster();
// Get compute instance which will only execute
// over remote nodes, i.e. not this node.
IgniteCompute compute = ignite.compute(cluster.forRemotes());
// Broadcast closure only to remote nodes.
compute.broadcast(new IgniteRunnable() {
    @Override public void run() {
        // Print ID of the node on which this runnable is executing.
        System.out.println(">>> Hello Node: " + ignite.cluster().localNode().id());
    }
});

2.3.1.预定义集群组

可以基于任何谓词创建集群组，为了方便Ignite也提供了一些预定义的集群组。
下面的例子显示了ClusterGroup接口中定义的部分集群组：

IgniteCluster cluster = ignite.cluster();
// Cluster group with remote nodes, i.e. other than this node.
ClusterGroup remoteGroup = cluster.forRemotes();

2.3.2.带节点属性的集群组

Ignite的唯一特点是所有节点都是平等的。没有master节点或者server节点，也没有worker节点或者client节点，按照Ignite的观点所有节点都是平等的。但是，可以将节点配置成master，worker，或者client以及data节点。
所有集群节点启动时都会自动将所有的环境和系统属性注册为节点的属性，但是也可以通过配置自定义节点属性。
XML：

<bean class="org.apache.ignite.IgniteConfiguration">
    ...
    <property name="userAttributes">
        <map>
            <entry key="ROLE" value="worker"/>
        </map>
    </property>
    ...
</bean>

Java：

IgniteConfiguration cfg = new IgniteConfiguration();
Map<String, String> attrs = Collections.singletonMap("ROLE", "worker");
cfg.setUserAttributes(attrs);
// Start Ignite node.
Ignite ignite = Ignition.start(cfg);

启动时，所有的环境变量和系统属性都会自动地注册为节点属性。
节点属性是通过ClusterNode.attribute("propertyName")属性获得的。

下面的例子显示了如何获得赋予了‘worker’属性值的节点：

IgniteCluster cluster = ignite.cluster();
ClusterGroup workerGroup = cluster.forAttribute("ROLE", "worker");
Collection<GridNode> workerNodes = workerGroup.nodes();

2.3.3.自定义集群组

可以基于一些谓词定义动态集群组，这个集群组只会包含符合该谓词的节点。
下面是一个例子，一个集群组只会包括CPU利用率小于50%的节点，注意这个组里面的节点会随着CPU负载的变化而改变。

IgniteCluster cluster = ignite.cluster();
// Nodes with less than 50% CPU load.
ClusterGroup readyNodes = cluster.forPredicate((node) -> node.metrics().getCurrentCpuLoad() < 0.5);

2.3.4.集群组组合

可以通过彼此之间的嵌套来组合集群组，比如，下面的代码片段显示了如何通过组合最老组和远程组来获得最老的远程节点：

// Group containing oldest node out of remote nodes.
ClusterGroup oldestGroup = cluster.forRemotes().forOldest();
ClusterNode oldestNode = oldestGroup.node();

2.3.5.从集群组中获得节点

可以像下面这样获得各种集群组的节点：

ClusterGroup remoteGroup = cluster.forRemotes();
// All cluster nodes in the group.
Collection<ClusterNode> grpNodes = remoteGroup.nodes();
// First node in the group (useful for groups with one node).
ClusterNode node = remoteGroup.node();
// And if you know a node ID, get node by ID.
UUID myID = ...;
node = remoteGroup.node(myId);

2.3.6.集群组指标数据

Ignite自动收集所有集群节点的指标数据，很酷的事是集群组会自动地收集组内所有节点的指标数据，然后提供组内正确的平均值，最小值，最大值等信息。
集群组指标数据是通过ClusterMetrics接口体现的，他包括了超过50个指标（注意，同样的指标单独的集群节点也有）。
下面的例子是获取一些指标数据，包括所有远程节点的平均CPU利用率以及可用堆大小：

// Cluster group with remote nodes, i.e. other than this node.
ClusterGroup remoteGroup = ignite.cluster().forRemotes();
// Cluster group metrics.
ClusterMetrics metrics = remoteGroup.metrics();
// Get some metric values.
double cpuLoad = metrics.getCurrentCpuLoad();
long usedHeap = metrics.getHeapMemoryUsed();
int numberOfCores = metrics.getTotalCpus();
int activeJobs = metrics.getCurrentActiveJobs();

2.4.领导者选举

2.4.1.摘要

当工作在分布式环境中时，有时需要确保有这么一个节点，不管网络是否发生变化，这个节点通常被叫做leader（领导者）。
很多系统选举领导者通常要处理数据一致性，然后通常是通过收集集群成员的选票处理的。而在Ignite中，数据一致性是通过数据网格的类似功能处理的（Rendezvous Hashing或者HRW哈希），选择领导者在传统意义上的数据一致性，在数据网格以外就不是真的需要了。
然而，可能还是希望有一个协调员节点来处理某些任务，为了这个，Ignite允许在集群中自动地选择最老的或者最新的节点。

使用服务网格
注意对于大多数领导者或者类单例用例中，建议使用服务网格功能，他可以自动地部署各个集群单例服务，而且更易于使用。

2.4.2.最老的节点

每当新节点加入时，最老的节点都有一个保持不变的属性，集群中的最老节点唯一发生变化的时间点就是它从集群中退出或者该节点故障。
下面的例子显示了如何选择一个集群组，他只包含了最老的节点。

IgniteCluster cluster = ignite.cluster();
// Dynamic cluster group representing the oldest cluster node.
// Will automatically shift to the next oldest, if the oldest
// node crashes.
ClusterGroup oldestNode = cluster.forOldest();

2.4.3.最新的节点

最新的节点，与最老的节点不同，每当新节点加入集群时都会不断发生变化，然而，有时他也会变得很灵活，尤其是如果希望只在最新的节点上执行一些任务时。
下面的例子显示了如何选择一个集群组，他只包含了最新的节点。

IgniteCluster cluster = ignite.cluster();
// Dynamic cluster group representing the youngest cluster node.
// Will automatically shift to the next youngest, if the youngest
// node crashes.
ClusterGroup youngestNode = cluster.forYoungest();

一旦获得了集群组，就可以用它执行任务、部署服务、发送消息等。

2.5.集群配置

2.5.1.摘要

Ignite中，通过DiscoverySpi节点可以彼此发现对方，Ignite提供了TcpDiscoverySpi作为DiscoverySpi的默认实现，它使用TCP/IP来作为节点发现的实现，可以配置成基于组播的或者基于静态IP的。

2.5.2.基于组播的发现

TcpDiscoveryMulticastIpFinder使用组播来发现网格内的每个节点。他也是默认的IP搜索器。除非打算覆盖默认的设置否则不需要指定他。
下面的例子显示了如何通过Spring XML配置文件或者通过Java代码编程式地进行配置：
Java：

TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();
ipFinder.setMulticastGroup("228.10.10.157");
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default discovery SPI.
cfg.setDiscoverySpi(spi);
// Start Ignite node.
Ignition.start(cfg);

XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
          <property name="multicastGroup" value="228.10.10.157"/>
        </bean>
      </property>
    </bean>
  </property>
</bean>

2.5.3.基于静态IP的发现

对于组播被禁用的情况，TcpDiscoveryVmIpFinder会使用预配置的IP地址列表。
唯一需要提供的就是至少一个远程节点的IP地址，但是为了保证冗余一个比较好的做法是在未来的某些时间点提供2-3个计划启动的网格节点的IP地址。只要建立了与任何一个已提供的IP地址的连接，Ignite就会自动地发现其他的所有节点。

TcpDiscoveryVmIpFinder默认用的是非共享模式，如果希望启动一个服务端节点，那么在该模式中的IP地址列表同时也要包含本地节点的一个IP地址。当其他节点加入集群过程中时，他会使该节点不用等待而是成为集群的第一个节点，并且正常运行。

下面的例子显示了如何通过Spring XML配置文件或者通过Java代码编程式地进行配置：
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
          <property name="addresses">
            <list>
              <!--
                  Explicitly specifying address of a local node to let it start
                  and operate normally even if there is no more nodes in the cluster.
                  You can also optionally specify an individual port or port range.
              -->
              <value>1.2.3.4</value>
              <!-- 
                  IP Address and optional port range of a remote node.
                  You can also optionally specify an individual port and don't set
                  the port range at all.
              -->
              <value>1.2.3.5:47500..47509</value>
            </list>
          </property>
        </bean>
      </property>
    </bean>
  </property>
</bean>

Java：

TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
// Set initial IP addresses.
// Note that you can optionally specify a port or a port range.
ipFinder.setAddresses(Arrays.asList("1.2.3.4", "1.2.3.5:47500..47509"));
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default discovery SPI.
cfg.setDiscoverySpi(spi);
// Start Ignite node.
Ignition.start(cfg);

2.5.4.基于组播和静态IP的发现

可以同时使用基于组播和静态IP的发现，这种情况下，除了通过组播接受地址以外，如果有的话，TcpDiscoveryMulticastIpFinder也可以与预配置的静态IP地址列表一起工作，就像上面描述的基于静态IP的发现一样。
下面的例子显示了如何配置使用了静态IP地址的组播IP搜索器。
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
          <property name="multicastGroup" value="228.10.10.157"/>
          <!-- list of static IP addresses-->
          <property name="addresses">
            <list>
              <value>1.2.3.4</value>
              <!-- 
                  IP Address and optional port range.
                  You can also optionally specify an individual port.
              -->
              <value>1.2.3.5:47500..47509</value>
            </list>
          </property>
        </bean>
      </property>
    </bean>
  </property>
</bean>

Java：

TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();
// Set Multicast group.
ipFinder.setMulticastGroup("228.10.10.157");
// Set initial IP addresses.
// Note that you can optionally specify a port or a port range.
ipFinder.setAddresses(Arrays.asList("1.2.3.4", "1.2.3.5:47500..47509"));
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default discovery SPI.
cfg.setDiscoverySpi(spi);
// Start Ignite node.
Ignition.start(cfg);

2.5.5.在同一个机器组中隔离Ignite集群

为了测试或者其他的一些原因，需要在同一个机器组中启动两个互相隔离的集群，这个是可以作为一个场景的。
对于TcpDiscoverySpi和TcpCommunicationSpi，不同集群的节点使用不交叉的本地端口范围，在Ignite中这个任务是可以做到的。
为了测试，假设需要在一个单个机器上启动两个互相隔离的集群，那么对于第一个集群的节点，需要使用如下的TcpDiscoverySpi和TcpCommunicationSpi配置：
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    ...
    <!--
        Explicitly configure TCP discovery SPI to provide list of 
        initial nodes from the first cluster.
    -->
    <property name="discoverySpi">
        <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
            <!-- Initial local port to listen to. -->
            <property name="localPort" value="48500"/>
            <!-- Changing local port range. This is an optional action. -->
            <property name="localPortRange" value="20"/>
            <!-- Setting up IP finder for this cluster -->
            <property name="ipFinder">
                <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
                    <property name="addresses">
                        <list>
                            <!--
                                Addresses and port range of the nodes from the first
                                cluster.
                                127.0.0.1 can be replaced with actual IP addresses or
                                host names. Port range is optional.
                            -->
                            <value>127.0.0.1:48500..48520</value>
                        </list>
                    </property>
                </bean>
            </property>
        </bean>
    </property>
    <!--
        Explicitly configure TCP communication SPI changing local
        port number for the nodes from the first cluster.
    -->
    <property name="communicationSpi">
        <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
            <property name="localPort" value="48100"/>
        </bean>
    </property>
</bean>

Java:

IgniteConfiguration cfg=new IgniteConfiguration();
// Explicitly configure TCP discovery SPI to provide list of initial nodes
// from the first cluster.
TcpDiscoverySpi discoverySpi=new TcpDiscoverySpi();
// Initial local port to listen to.
discoverySpi.setLocalPort(48500);
// Changing local port range. This is an optional action.
discoverySpi.setLocalPortRange(20);
TcpDiscoveryVmIpFinder ipFinder=new TcpDiscoveryVmIpFinder();
// Addresses and port range of the nodes from the first cluster.
// 127.0.0.1 can be replaced with actual IP addresses or host names.
// The port range is optional.
ipFinder.setAddresses(Arrays.asList("127.0.0.1:48500..48520"));
// Overriding IP finder.
discoverySpi.setIpFinder(ipFinder);
// Explicitly configure TCP communication SPI by changing local port number for
// the nodes from the first cluster.
TcpCommunicationSpi commSpi=new TcpCommunicationSpi();
commSpi.setLocalPort(48100);
// Overriding discovery SPI.
cfg.setDiscoverySpi(discoverySpi);
// Overriding communication SPI.
cfg.setCommunicationSpi(commSpi);
// Starting a node.
Ignition.start(cfg);

而对于第二个集群的节点，配置看起来是这样的：
XML：

<bean id="ignite.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
    <!--
        Explicitly configure TCP discovery SPI to provide list of initial
         nodes from the second cluster.
    -->
    <property name="discoverySpi">
        <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
            <!-- Initial local port to listen to. -->
            <property name="localPort" value="49500"/>
            <!-- Changing local port range. This is an optional action. -->
            <property name="localPortRange" value="20"/>
            <!-- Setting up IP finder for this cluster -->
            <property name="ipFinder">
                <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
                    <property name="addresses">
                        <list>
                            <!--
                                Addresses and port range of the nodes from the second
                                cluster.
                                127.0.0.1 can be replaced with actual IP addresses or
                                host names. Port range is optional.
                            -->
                            <value>127.0.0.1:49500..49520</value>
                        </list>
                    </property>
                </bean>
            </property>
        </bean>
    </property>
    <!--
        Explicitly configure TCP communication SPI changing local port number 
        for the nodes from the second cluster.
    -->
    <property name="communicationSpi">
        <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
            <property name="localPort" value="49100"/>
        </bean>
    </property>
</bean>

Java:

IgniteConfiguration cfg=new IgniteConfiguration();
// Explicitly configure TCP discovery SPI to provide list of initial nodes
// from the second cluster.
TcpDiscoverySpi discoverySpi=new TcpDiscoverySpi();
// Initial local port to listen to.
discoverySpi.setLocalPort(49500);
// Changing local port range. This is an optional action.
discoverySpi.setLocalPortRange(20);
TcpDiscoveryVmIpFinder ipFinder=new TcpDiscoveryVmIpFinder();
// Addresses and port range of the nodes from the second cluster.
// 127.0.0.1 can be replaced with actual IP addresses or host names.
// The port range is optional.
ipFinder.setAddresses(Arrays.asList("127.0.0.1:49500..49520"));
// Overriding IP finder.
discoverySpi.setIpFinder(ipFinder);
// Explicitly configure TCP communication SPI by changing local port number for
// the nodes from the second cluster.
TcpCommunicationSpi commSpi=new TcpCommunicationSpi();
commSpi.setLocalPort(49100);
// Overriding discovery SPI.
cfg.setDiscoverySpi(discoverySpi);
// Overriding communication SPI.
cfg.setCommunicationSpi(commSpi);
// Starting a node.
Ignition.start(cfg);

从配置中可以看到，他们的差别是很小的 - 只是SPI的端口号和IP搜索器不同。

如果希望不同集群的节点之间可以互相检索到，可以使用组播协议然后将TcpDiscoveryVmIpFinder替换为TcpDiscoveryMulticastIpFinder并且在上面的每个配置中设置唯一的TcpDiscoveryMulticastIpFinder.multicastGroups。

2.5.6.基于Apache Jcloud的发现

参照2.9.JCoud集成章节

2.5.7.基于Amazon S3的发现

参照2.7.Amazon AWS集成章节

2.5.8.基于GCS的发现

参照2.8.Google云集成章节

2.5.9.基于JDBC的发现

可以用数据库作为通用共享存储来保存初始的IP地址，这些节点会在启动时将IP地址写入数据库，这是通过TcpDiscoveryJdbcIpFinder实现的。
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.jdbc.TcpDiscoveryJdbcIpFinder">
          <property name="dataSource" ref="ds"/>
        </bean>
      </property>
    </bean>
  </property>
</bean>
<!-- Configured data source instance. -->
<bean id="ds" class="some.Datasource">
  ...
</bean>

Java：

TcpDiscoverySpi spi = new TcpDiscoverySpi();
// Configure your DataSource.
DataSource someDs = MySampleDataSource(...);
TcpDiscoveryJdbcIpFinder ipFinder = new TcpDiscoveryJdbcIpFinder();
ipFinder.setDataSource(someDs);
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default discovery SPI.
cfg.setDiscoverySpi(spi);
// Start Ignite node.
Ignition.start(cfg);

2.5.10.基于ZooKeeper的发现

如果使用ZooKeeper 来整合分布式环境，也可以利用它进行Ignite节点的发现，这是通过TcpDiscoveryZookeeperIpFinder实现的（注意需要启用ignite-zookeeper模块）。
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    ...
    <property name="discoverySpi">
        <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
            <property name="ipFinder">
                <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder">
                    <property name="zkConnectionString" value="127.0.0.1:2181"/>
                </bean>
            </property>
        </bean>
    </property>
</bean>

Java:

TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryZookeeperIpFinder ipFinder = new TcpDiscoveryZookeeperIpFinder();
// Specify ZooKeeper connection string.
ipFinder.setZkConnectionString("127.0.0.1:2181");
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default discovery SPI.
cfg.setDiscoverySpi(spi);
// Start Ignite node.
Ignition.start(cfg);

2.5.11.故障检测超时

故障检测超时用于确定一个集群节点在与远程节点连接失败时可以等待多长时间，根据集群的硬件和网络条件，这个超时时间是调整发现SPI的故障检测功能的最简单的方式。

这些TcpDiscoverySpi的超时配置参数是自动控制的，比如套接字超时，消息确认超时以及其他的，如果显式地设置了这些参数中的任意一个，故障超时设置都会被忽略掉。

故障检测超时是通过IgniteConfiguration.setFailureDetectionTimeout(long failureDetectionTimeout)方法来配置的，默认值是10秒，这个时间可以使发现SPI在大多数的硬件和虚拟环境下可靠地工作，但是这已经使故障检测很糟糕了。然而，对于一个稳定低延迟网络来说，这个参数设置成大约200毫秒会更有助于快速地进行故障的检测和响应。

2.5.12.配置

下面的配置参数可以对TcpDiscoverySpi进行可选的配置：

2.6.零部署

2.6.1.摘要

计算所需的闭包和任务可能是任意自定义的类，也包括匿名类。Ignite中，远程节点会自动感知这些类，不需要显式地将任何jar文件部署或者移动到任何远程节点上。

2.6.2.对等类加载

这个行为是通过对等类加载（P2P类加载）实现的，他是Ignite中的一个特别的分布式类加载器，实现了节点间的字节码交换。当对等类加载启用时，不需要在网格内的每个节点上手工地部署Java或者Scala代码，也不需要每次在发生变化时重新部署。
下面的代码由于对等类加载会在所有的远程节点上运行，不需要任何的显式部署步骤：

IgniteCluster cluster = ignite.cluster();
// Compute instance over remote nodes.
IgniteCompute compute = ignite.compute(cluster.forRemotes());
// Print hello message on all remote nodes.
compute.broadcast(() -> System.out.println("Hello node: " + cluster.localNode().id()));

下面是对等类加载如何配置：
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    ...   
    <!-- Explicitly enable peer class loading. -->
    <property name="peerClassLoadingEnabled" value="true"/>
    ...
</bean>

Java：

IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setPeerClassLoadingEnabled(true);
// Start Ignite node.
Ignite ignite = Ignition.start(cfg);

对等类加载的工作步骤如下：

1. Ignite会检查类是否在本地CLASSPATH中有效（是否在系统启动时加载），如果有效，就会被返回。这时不会发生从对等节点加载类的行为。
2. 如果类本地不可用，会向初始节点发送一个提供类定义的请求，初始节点会发送类字节码定义然后类会在工作节点上加载。这个每个类只会发生一次-一旦一个节点上一个类定义被加载了，他就不会再次加载了。

热部署自动缓存清理
BinaryMarshaller（默认）是支持热部署的，如果不使用默认的BinaryMarshaller，那么每当改变了存储在缓存中的类定义时，Ignite会在对等部署新数据之前自动清理缓存中之前的类定义，以避免类加载冲突。
第三方库
当使用对等类加载时，会发现可能从对等节点加载库，还可能本地类路径就已经存在库。建议在每个节点的类路径里包含所有的第三方库，这可以通过将jar文件复制到Ignite的libs文件夹实现，这样就可以避免每次只改变了一行代码然后还需要向远程节点上传输若干M的第三方库文件。

2.6.3.显式部署

要在Ignite中显式地部署jar文件，可以将他们拷贝进每个集群节点的libs文件夹，Ignite会在启动时自动加载所有的libs文件夹中的jar文件。

2.7.部署模式

2.7.1.摘要

对等类加载行为的特性是由不同的部署模式控制的。特别地，当发起节点离开网格时的卸载行为也会依赖于部署模式。另一方面，由部署模式，是用户资源管理和类版本管理。在下面的章节中会更详细地描述每个部署模式。
PRIVATE和ISOLATED
在主节点，同一个类加载器部署的类，还会在worker节点远程共享同一个类加载器。然而，从不同主节点部署的任务不会在worker节点共享同一个类加载器，这对于开发很有用，这时不同的开发者可以工作于同一个类的不同版本上。
自从@UserResource注解删除后，PRIVATE和ISOLATED部署模式就没有不同了。这两个常量都因为后向兼容的原因保留了，并且这两个之一可能在未来的大版本中被删除。
这个模式中，当主节点离开集群时，类会卸载。
SHARED
这是默认的部署模式。这个模式中，来自不同主节点的、用户版本相同的类会在worker节点上共享同一个类加载器。当所有主节点离开网格或者用户版本发生变化时，类会卸载。这个模式可以使来自不同主节点的类在远程节点上共享用户资源的同一个实例（见下面）。这个模式对于产品环境特别有用，与ISOLATED模式相比，它在单一主节点上有一个单一类加载器的作用域，SHARED模式会向所有主节点扩展部署作用域。
这个模式中，当所有的主节点离开集群时，类会卸载。
CONTINUOUS
在CONTINUOUS模式中，当主节点离开网格时类不会卸载。卸载只会发生于类的用户版本发生变化时。这个方式的优势是可以使来自不同主节点的任务在worker节点共享同一个用户资源的实例（参见资源注入），这使得在worker节点上执行的所有任务可以复用，比如，连接池或者缓存的同一个实例。当用这个模式时，可以启动多个独立的worker节点，在主节点定义用户资源并且在worker节点上初始化一次，不管他们来自那个主节点。与ISOLATED部署模式相比，它在单一主节点上有一个单一类加载器的作用域，CONTINUOUS模式会向所有主节点扩展部署作用域，这对于产品模式非常有用。
这个模式中，即使所有的主节点离开集群，类都不会卸载。

2.7.2.卸载和用户版本

通过对等类加载获得的类定义，有他们自己的生命周期。在特定的事件中（当主节点离开或者用户版本变化，依赖于部署模式），类信息会从网格中卸载，类定义会从网格中的所有节点和用户资源抹掉，与该类链接的，也会有选择地抹掉（还是依赖于部署模式）。对于内存数据网格，还意味着一个卸载的类的所有缓存条目都会从缓存删除。然而，如果使用了二进制编组器，后者并不适用，它允许以二进制的形式存储缓存数据来避免从一个主节点加载条目的必要性。
当部署于SHARED和CONTINUOUS模式时，如果想重新部署类，用户版本来了。Ignite默认会自动检测类加载器是否改变或者一个节点是否重新启动。然而，如果希望在节点的一个子集上改变或者重新部署代码，或者在CONTINUOUS模式中，杀掉所有的现存部署，那么需要修改用户版本。
用户版本是在类路径的META-INF/ignite.xml中指定的，像下面这样：

<!-- User version. -->
<bean id="userVersion" class="java.lang.String">
    <constructor-arg value="0"/>
</bean>

所有的Ignite启动脚本（ignite.sh或者ignite.bat）默认都会从IGNITE_HOME/config/userversion文件夹获取用户版本。通常，在这个文件夹中更新用户版本就够了，然而，当使用GAR或者JAR部署时，需要记得提供一个META-INF/ignite.xml文件，里面有期望的用户版本。

2.7.3.配置

下面的对于对等类加载的配置参数可以在IgniteConfiguration中进行可选的配置：

XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!--
        Explicitly enable peer class loading. Set to false
        to disable the feature.
    -->
    <property name="peerClassLoadingEnabled" value="true"/>
    <!-- Set deployment mode. -->
    <property name="deploymentMode" value="CONTINUOUS"/>
    <!-- Disable missed resources caching. -->
    <property name="peerClassLoadingMissedResourcesCacheSize" value="0"/>
    <!--
        Exclude force peer class loading of a class,
        even if exists locally.
    -->
    <property name="peerClassLoadingLocalClassPathExclude">
        <list>
            <value>com.mycompany.MyChangingClass</value>
        </list>
    </property>
</bean>

Java：

IgniteConfiguration cfg=new IgniteConfiguration();
// Explicitly enable peer class loading.
cfg.setPeerClassLoadingEnabled(true);
// Set deployment mode.
cfg.setDeploymentMode(DeploymentMode.CONTINUOUS);
// Disable missed resource caching.
cfg.setPeerClassLoadingMissedResourcesCacheSize(0);
// Exclude force peer class loading of a class, 
// even if it exists locally.
cfg.setPeerClassLoadingLocalClassPathExclude("com.mcompany.MyChangingClass");
// Start a node.
Ignition.start(cfg);

2.8.网络配置

CommunicationSpi为发送和接收网格消息提供了基本的管道，他也被用于所有的分布式网格操作，比如执行任务，监控数据交换，分布式事件查询以及其他的。Ignite提供了TcpCommunicationSpi作为CommunicationSpi的默认实现，它使用TCP/IP协议来进行节点间的通信。
要启用节点间的通信，TcpCommunicationSpi增加了TcpCommuncationSpi.ATTR_ADDRS和TcpCommuncationSpi.ATTR_PORT本地节点属性。启动时，这个SPI会监听由TcpCommuncationSpi.setLocalPort(int)方法设置的本地端口。如果端口被占用，SPI会自动增加端口号直到成功绑定监听。
TcpCommuncationSpi.setLocalPortRange(int)配置参数控制了SPI可以尝试的最大端口数量。
本地端口范围
当在一台机器上甚至是在同一个JVM上启动多个网格节点时，端口范围会非常方便，这样的话所有的节点都会启动而不用一个个地进行单独的配置。
下面的例子显示了如何调整TcpCommunicationSpi的参数：
XML：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="communicationSpi">
    <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
      <!-- Override local port. -->
      <property name="localPort" value="4321"/>
    </bean>
  </property>
  ...
</bean>

Java：

TcpCommunicationSpi commSpi = new TcpCommunicationSpi();
// Override local port.
commSpi.setLocalPort(4321);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default communication SPI.
cfg.setCommunicationSpi(commSpi);
// Start grid.
Ignition.start(cfg);

2.9.Docker部署

Docker可以将Ignite应用及其所有的依赖打包进一个标准的容器，Docker会自动下载Ignite发布版，将代码部署进Ignite以及配置节点，他还可以自动启动配置好的Ignite节点，这样的集成方式，使得通过简单地重启Ignite的Docker容器就可以部署新的代码。

2.9.1.启动Ignite Docker容器

要运行Docker容器，需要拉取然后启动一个Docker映像，默认会下载最新的版本，但是在这里可以看到一个完整的清单。
可以使用如下的命令拉取Ignite docker映像：

# Pull latest version.
sudo docker pull apacheignite/ignite
# Pull ignite version {ignite-version}
sudo docker pull apacheignite/ignite:{ignite-version}

可以使用docker run来运行Ignite docker容器：

# Run latest version.
sudo docker run -it --net=host 
-e "CONFIG_URI=$CONFIG_URI" 
[-e "OPTION_LIBS=$OPTION_LIBS"]
[-e "JVM_OPTS=$JVM_OPTS"]
...
apacheignite/ignite 
# Run ignite version {ignite-version}
sudo docker run -it --net=host 
-e "CONFIG_URI=$CONFIG_URI" 
[-e "OPTION_LIBS=$OPTION_LIBS"]
[-e "JVM_OPTS=$JVM_OPTS"]
...
apacheignite/ignite:{ignite-version}

配置参数可以通过docker容器的环境变量进行传递，可用的配置参数如下：

2.9.2.示例

要启动Ignite的docker容器，可以使用如下的命令：

sudo docker run -it --net=host -e "IGNITE_CONFIG=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml" apacheignite/ignite

之后应该看到如下的输出日志：

2.10.AWS部署

Ignite的AMI（Amazon机器映像）可以通过AWS的EC2管理控制台配置一个简单的Ignite集群，通过AMI进行安装，可以快速地部署一个Ignite集群。

2.10.1.Amazon EC2部署

• 点击下表的链接选择必要的区域：

或者，也可以使用Apache Ignite关键字在Community AMIs中搜索映像：

- 选择一个Instance Type;
- 打开Configure Instance并且展开Advanced Details;
- 添加下面的任意配置参数；

如下图所示：

首选Ignite版本
IGNITE_VERSION属性可以视具体情况而定。

• 在Tag Instance，设置name标签，比如ignite-node;
• 复查然后运行实例；
• 连接实例：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide;
• 要查看执行的过程，需要知道容器的id，可以使用如下命令：

sudo docker ps

• 显示日志：

sudo docker logs -f CONTAINER_ID

• 进入docker容器：

sudo docker exec -it container_id /bin/bash

2.11.Google计算部署

Ignite的映像可以通过Google计算控制台配置一个简单的Ignite集群，通过映像进行安装，可以快速地部署一个Ignite集群。

2.11.1.Google计算部署

• 要导入Ignite映像，执行如下的命令：

gcloud compute images create ignite-image \
   --source-uri gs://ignite-media/ignite-google-image.tar.gz

要了解更多信息，可以参照cloud.google.com。

• 打开Google Compute Console；
• 打开Compute->Compute Engine->VM实例，然后点击New instance；
• 点击Boot disk的Change按钮；

• 打开Custom images，然后选择已导入的映像，在下面的截图中，可以看到名为ignite-name的映像；
  

• 点击Management, disk, networking, access & security options，然后可以添加任意的配置参数：

如下图所示：

首选Ignite版本
IGNITE_VERSION属性可以视具体情况而定。

• 填写必要的属性然后运行实例；
• 连接实例;
• 要查看执行的过程，需要知道容器的id，可以使用如下命令：

sudo docker ps

• 显示日志：

sudo docker logs -f CONTAINER_ID

• 进入docker容器：

sudo docker exec -it container_id /bin/bash

2.12.Mesos部署

2.12.1.摘要

Apache Ignite支持在Mesos集群上调度和运行Ignite节点。
Apache Mesos是一个集群管理器，他提供了一个通用运行环境以及所有的必要资源来部署、运行和管理分布式应用。他对资源的管理和隔离有助于充分利用服务器资源。
要了解Apache Mesos的更多信息，请参照：http://mesos.apache.org/

2.12.2.Ignite Mesos框架

典型的部署Apache Ignite集群需要下载Apache Ignite发行版，修改配置参数以及启动节点。Apache Ignite Mesos框架由调度器和任务组成，可以极大地简化集群的部署。

• 调度器：调度器启动时将自己注册成Mesos主节点，一旦注册成功调度器就会开始处理从Mesos主节点到使用资源的Ignite节点的资源请求，调度器会维护Ignite集群所需的所有资源水平（CPU，内存等）；
• 任务：从节点运行Ignite节点的实体。

2.12.3.运行Ignite Mesos框架

要运行Ignite Mesos框架需要配置好的正在运行的Apache Mesos集群，如果需要如何Apache Mesos集群的信息，请参照：https://docs.mesosphere.com/getting-started/datacenter/install/。

确保主节点和从节点监听正确的IP地址，否则无法保证Mesos集群能正常工作。

通过Marathon运行框架
当前建议的做法是通过Marathon运行框架。

• 安装Marathon，参照：https://docs.mesosphere.com/getting-started/datacenter/install/marathon章节；
• 下载Apache Ignite然后将libs\optional\ignite-mesos\ignite-mesos-<ignite-version>-jar-with-dependencies.jar上传到任意一个云存储（比如Amazon S3yun）；
• 拷贝下面的应用定义（JSON格式）然后保存成marathon.json文件，然后对参数做必要的修改，如果未对集群进行限制那么框架会试图占用Mesos集群的所有资源，可以看下面的配置章节；

 {
  "id": "ignition",
  "instances": 1,
  "cpus": 2,
  "mem": 2048,
  "ports": [0],
  "uris": [
    "http://host/ignite-mesos-<ignite-version>-jar-with-dependencies.jar"
  ],
  "env": {
    "IGNITE_NODE_COUNT": "4",
    "MESOS_MASTER_URL": "zk://localhost:2181/mesos",
    "IGNITE_RUN_CPU_PER_NODE": "2",
    "IGNITE_MEMORY_PER_NODE": "2048",
    "IGNITE_VERSION": "1.0.5"
  },
  "cmd": "java -jar ignite-mesos-<ignite-version>-jar-with-dependencies.jar"
}

• 通过curl等工具发送应用定义的POST请求给Marathon：

curl -X POST -H "Content-type: application/json" --data-binary @marathon.json http://<marathon-ip>:8080/v2/apps/

• 为了确保Apache Mesos框架部署正确，可以这么做，打开Marathon界面http://<marathon-ip>:8080，确保已有的应用名字为ignition而且状态是Running；
  
• 打开Mesos控制台http://<master-ip>:5050，如果一切正常那么任务的名字类似Ignite node N，状态是RUNNING。在本示例中，N=4，可以看示例中的marathon.json文件-"IGNITE_NODE_COUNT": "4"；
  
• Mesos允许通过浏览器获得任务的日志，要查看Ignition的日志可以点击Active Tasks表格中的Sandbox；
  
• 点击stdout获取标准输出日志，stderr获取标准错误日志；
  
  通过jar文件运行框架
• 下载Ignite包然后打开libs\optional\ignite-mesos\文件夹；
• 运行框架：java -jar ignite-mesos--jar-with-dependencies.jar 或者java -jar ignite-mesos--jar-with-dependencies.jar properties.prop，其中properties.prop是一个配置文件，如果不提供配置文件那么框架会试图占用Mesos集群的所有资源，下面是一个例子：

# The number of nodes in the cluster.
IGNITE_NODE_COUNT=1
# Mesos ZooKeeper URL to locate leading master.
MESOS_MASTER_URL=zk://localhost:2181/mesos
# The number of CPU Cores for each Apache Ignite node.
IGNITE_RUN_CPU_PER_NODE=4
# The number of Megabytes of RAM for each Apache Ignite node.
IGNITE_MEMORY_PER_NODE=4096
# The version ignite which will be run on nodes.
IGNITE_VERSION=1.7.0

• 为了确保Apache Mesos框架部署正确，可以这么做，打开Marathon界面http://<marathon-ip>:5050，确保已有的应用名字为ignition而且状态是Running。在本示例中N=1，可以看示例中的properties.prop文件-"IGNITE_NODE_COUNT": "1"；
  
• Mesos允许通过浏览器获得任务的日志，要查看Ignition的日志可以点击Active Tasks表格中的Sandbox；
  
• 点击stdout获取标准输出日志，stderr获取标准错误日志；
  

2.12.4.配置

所有配置都是通过环境变量或者配置文件处理的（这非常适用于简化marathon的配置以运行框架），下面的配置参数可以根据需要进行配置：

2.13.Yarn部署

2.13.1.摘要

与Yarn的集成可以支持在Yarn集群上调度和运行Apache Ignite节点。
Yarn是一个资源管理器，他提供了一个包括所有必要资源的通用的运行环境来进行分布式应用的部署，运行和管理，他对资源的管理和隔离有助于充分利用服务器资源。
要了解Yarn的信息，请参照http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html。

2.13.2.Ignite Yarn应用

部署Apache Ignite集群的典型步骤是下载Ignite的发行版，修改配置文件以及启动节点。与Yarn的集成可以避免这些操作，Ignite Yarn应用可以极大的简化集群的部署，它由如下组件组成：

• 下载Ignite发行版，将必要的资源放入HDFS，创建启动任务的必要的上下文，启动Application master进程；
• Application master：一旦注册成功组件就会开始处理从资源管理器到使用资源的Ignite节点的资源请求，Application master会维护Ignite集群所需的所有资源水平（CPU，内存等）；
• Container：在从节点上运行Ignite节点的实体；

2.13.3.运行Ignite Yarn应用

要运行Ignite应用，需要配置和运行Yarn和Hadoop集群，要了解如何配置集群的信息，可以参照： http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/ClusterSetup.html.

• 下载Ignite；
• 配置属性文件，修改必要的参数，可以参照下面的配置章节：

# The number of nodes in the cluster.
IGNITE_NODE_COUNT=2
# The number of CPU Cores for each Apache Ignite node.
IGNITE_RUN_CPU_PER_NODE=1
# The number of Megabytes of RAM for each Apache Ignite node.
IGNITE_MEMORY_PER_NODE=2048
# The version ignite which will be run on nodes.
IGNITE_VERSION=1.0.6

• 运行应用；

hadoop java jar ignite-yarn-<ignite-version>.jar ./ignite-yarn-<ignite-version>.jar cluster.properties

• 为了确保应用正确部署，可以这样做：打开Yarn控制台http://:8088/cluster，看名字为Ignition的应用是否工作正常；
  
• 可以从浏览器获得日志，要查看日志可以点击任意容器的Logs；
  
• 点击stdout获取标准输出日志，stderr获取标准错误日志；
  

2.13.4.配置

所有的配置都是通过环境变量和属性文件进行的，下面的配置参数可以根据需要进行配置：

2.14.SSL和TLS

2.14.1.节点间的安全连接

Ignite允许在所有节点之间使用SSL Socket进行通信。要使用SSL，需要设置Factory<SSLContext>以及配置Ignite配置文件的SSL段落，Ignite提供了一个默认的SSL上下文工厂，org.apache.ignite.ssl.SslContextFactory，他用一个配置好的keystore来初始化SSL上下文。
XML：

<bean id="cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
  <property name="sslContextFactory">
    <bean class="org.apache.ignite.ssl.SslContextFactory">
      <property name="keyStoreFilePath" value="keystore/server.jks"/>
      <property name="keyStorePassword" value="123456"/>
      <property name="trustStoreFilePath" value="keystore/trust.jks"/>
      <property name="trustStorePassword" value="123456"/>
    </bean>
  </property>
</bean>

Java：

IgniteConfiguration igniteCfg = new IgniteConfiguration();
SslContextFactory factory = new SslContextFactory();
factory.setKeyStoreFilePath("keystore/server.jks");
factory.setKeyStorePassword("123456".toCharArray());
factory.setTrustStoreFilePath("keystore/trust.jks");
factory.setTrustStorePassword("123456".toCharArray());
igniteCfg.setSslContextFactory(factory);

某些情况下需要禁用客户端侧的证书认证（比如连接到一个自签名的服务器时），这可以通过给上述工厂设置禁用信任管理器实现，他可以通过getDisabledTrustManager获得。
XML:

<bean id="cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
  <property name="sslContextFactory">
    <bean class="org.apache.ignite.ssl.SslContextFactory">
      <property name="keyStoreFilePath" value="keystore/server.jks"/>
      <property name="keyStorePassword" value="123456"/>
      <property name="trustManagers">
        <bean class="org.apache.ignite.ssl.SslContextFactory" factory-method="getDisabledTrustManager"/>
     </property>
    </bean>
  </property>
</bean>

Java:

IgniteConfiguration igniteCfg = new IgniteConfiguration();
SslContextFactory factory = new SslContextFactory();
factory.setKeyStoreFilePath("keystore/server.jks");
factory.setKeyStorePassword("123456".toCharArray());
factory.setTrustManagers(SslContextFactory.getDisabledTrustManager());
igniteCfg.setSslContextFactory(factory);

如果配置了安全，那么日志就会包括：communication encrypted=on

INFO: Security status [authentication=off, communication encrypted=on]

2.14.2.SSL和TLS

Ignite允许使用不同的加密类型，支持的加密算法可以参照：http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext,可以通过setProtocol()方法进行设置，默认值是TLS。
XML：

<bean id="cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
  <property name="sslContextFactory">
    <bean class="org.apache.ignite.ssl.SslContextFactory">
      <property name="protocol" value="SSL"/>
      ...
    </bean>
  </property>
  ...
</bean>

Java：

IgniteConfiguration igniteCfg = new IgniteConfiguration();
SslContextFactory factory = new SslContextFactory();
...
factory.setProtocol("TLS");
igniteCfg.setSslContextFactory(factory);

2.14.3.配置

下面的配置参数可以通过SslContextFactory进行配置：

2.15.资源注入

2.15.1.摘要

Ignite中，预定义的资源都是可以进行依赖注入的，同时支持基于属性和基于方法的注入。任何加注正确注解的资源都会在初始化之前注入相对应的任务、作业、闭包或者SPI。

2.15.2.基于属性和基于方法

可以通过在一个属性或者方法上加注注解来注入资源。当加注在属性上时，Ignite只是在注入阶段简单地设置属性的值（不会理会该属性的访问修饰符）。如果在一个方法上加注了资源注解，他会访问一个与注入资源相对应的输入参数的类型，如果匹配，那么在注入阶段，就会将适当的资源作为输入参数，然后调用该方法。
基于属性：

Ignite ignite = Ignition.ignite();
Collection<String> res = ignite.compute().broadcast(new IgniteCallable<String>() {
    // Inject Ignite instance.  
    @IgniteInstanceResource
    private Ignite ignite;
    @Override
    public String call() throws Exception {
        IgniteCache<Object, Object> cache = ignite.getOrCreateCache(CACHE_NAME);
        // Do some stuff with cache.
        ...
    }
});

基于方法：

public class MyClusterJob implements ComputeJob {
    ...
    private Ignite ignite;
    ...
    // Inject Ignite instance.  
    @IgniteInstanceResource
    public void setIgnite(Ignite ignite) {
        this.ignite = ignite;
    }
    ...
}

2.15.3.预定义的资源

有很多的预定义资源可供注入：