Apache Ignite 学习笔记(四): Ignite缓存冗余备份策略

Ignite的数据网格是围绕着基于内存的分布式key/value存储能力打造的。当初技术选型的时候，决定用Ignite也是因为虽然同样是key/value存储，它有着和其他key/value存储系统不同的特性。根据官网的介绍，Ignite在设计之初，就是为了能方便的水平扩展而设计的。Ignite将数据分片，每个节点只存储数据的一部分，这样每当有新节点加入时，整个集群可以存储更多的数据。为了提高可用性，Ignite也支持用不同的策略对数据分片进行冗余备份，这样保证数据不会因为集群中一两个节点失效而丢失。另外，和其他key/value缓存系统最大的不同是，Ignite支持用SQL语句对缓存数据进行查询。正是由于有对SQL 99的支持，我们甚至可以把Ignite当做一个分布式内存数据库来使用。

从这篇文章开始，我们先聚焦在Ignite提供的数据网格服务上，看看同样是基于key/value存储，Ignite的key/value缓存又提供了哪些能力。

消失的数据

在介绍Ignite不同的缓存冗余备份模式之前，我们先用上一篇文章的代码来模拟一下在默认配置下，如果Ignite集群中有节点失效，我们的数据是否还完整有效。我们在同一台虚拟机按以下的顺序分别启动server和client实例:

启动一个server实例，该实例会创建一个“TEST”缓存并写入三条缓存数据。
再启动一个server实例，该实例会自动加入之前启动的server节点，组成一个Ignite集群。因为该实例创建的缓存名字和写入的缓存数据都一样，所以"TEST"缓存里的数据保持不变。
启动一个client实例，查询“TEST”缓存里的数据，此时该client应该可以查询到三条之前写入的缓存数据：

Montreal is in Quebec

Edmonton is in Alberta

Markham is in Ontario

Toronto is in null

关闭一个server实例，再启动一个client实例做查询，此时我们会发现某些缓存数据消失了。比如在我的环境里，就查不到Markham这条数据了：

Montreal is in Quebec

Edmonton is in Alberta

Markham is in null

Toronto is in null

因为Ignite将缓存数据分片存储的，即同一缓存中的不同数据存到不同的server节点上，Ignite通过一个哈希算法计算出某个数据分片所属的节点。除了原生的哈希算法，用户也可实现自己的哈希算法来决定数据分片对应的节点。在上面的步骤1中，缓存数据全部存在仅有的唯一一个server实例中。在步骤2中，当有新的server实例加入集群，Ignite通过默认的哈希算法决定哪部分的数据分片应该存到新加入的server实例中，然后将数据在两个实例间重新平衡分布。由于我们采用的是默认的配置，所以每个数据分片只有一份拷贝，这就是为什么当我们关了一个server实例后会发生数据丢失的情况。因此，为了保证数据的高可用，我们必须调整数据分片拷贝的数量。接下来，我们就来看看Ignite提供了哪些对数据分片进行冗余备份的策略，以便用户根据实际需求在性能和数据高可用性之间做选择。

Ignite缓存数据分片冗余策略

Local模式

我们先从简单的模式说起，Local模式，顾名思义就是缓存的所有数据只保存在本地节点，数据不会分布到其他节点上，也就没有数据分片和数据拷贝这么一说。Local模式的最大好处是它的轻量化，因为没有了数据分片和冗余备份的负担,其非常适合于数据只读模式和需要定期刷新的场景，也适合于作为一个read-through的缓存。除了数据分布不同，采用local模式的缓存和分布式缓存有着相同的功能，比如数据自动清除，过期失效，磁盘交换，数据查询以及事务等特性。

Replicated模式

Replicated模式下，缓存数据虽然被均分为多个数据分片，但每个节点上都有该缓存的全部数据分片。下面这张官网图很好的展示了replicated模式的数据分布：

在replicated模式下，缓存数据被平分为4个数据分片A、B、C、D。在节点1(JVM1)上有分片A的primary拷贝和B、C、D的backup拷贝。在节点2(JVM2)上有分片C的primary拷贝和A、B、D的backup拷贝。节点3(JVM3)和节点4(JVM4)的情况也类似。关于数据分片的primary和backup拷贝的概念我们在下一篇介绍，这里只要记住当primary拷贝失效了，Ignite可以用backup拷贝恢复数据，保证了数据的高可靠性。所以在replicated模式下，每个节点其实有缓存的所有数据分片拷贝，即便集群里其他节点都失效，Ignite还是可以通过仅存的一个节点提供数据读写服务

Partitioned模式

Partition模式下，缓存数据被均分为多个数据分片，数据分片的拷贝均等的分布在集群的某些节点上。换句话说，和replicated模式最大的不同就是，一个节点上没有全部的缓存数据分片拷贝。让我们借用官网的图来解释一下partitioned模式：

如上图所示，在partitioned模式下，缓存数据被平分为4个数据分片A、B、C、D，每个数据分片有一份primary拷贝和backup拷贝，所以每个节点只保存两个数据分片的拷贝，比如节点1(JVM1)有分片A的primary分片和分片B的backup分片，节点2(JVM2)有分片C的primary分片和分片A的backup分片。Backup拷贝的数量是用户可配置的，如果配置为0时，代表着一个数据分片没有副本，一旦某个节点挂了，数据就会丢失。如果配置为(集群节点数量-1)，代表着集群的每个节点上都有一份该数据分片的拷贝，这就相当于一种特殊的replicated模式。拷贝数量越多，代表数据约可靠，但也会带来额外的开销，所以我们还是要根据实际的场景和需求来调整拷贝数量。

Replicated V.S. Partitioned

让我们简单的比较下两种模式的优缺点以及它们适合的场景：

首先，从数据的可靠性来说当然是replicated模式占优势，毕竟每个节点都有缓存的所有数据分片，只要集群中有一个节点还能工作，就能从该节点恢复数据。而partitioned模式下，数据的可靠性是和backup数量N相关的，在partitioned模式下，一旦有N+1个节点失效，集群就有可能出现丢失数据的情况。
其次，从扩展性上看，是partitioned模式优于replicated模式。因为每个节点需要有所有数据分片的拷贝，在replicated模式下，集群所能容纳的数据大小是受单个节点的内存和硬盘(如果启用了Ignite原生的持久化功能)限制的，即便新增节点，也不能提高集群的数据容量。反观partitioned模式，新增加一个节点就可以给集群增加更多的存储能力，容纳更多的数据。
再次，从读写性能上看，replicated模式适合多读少写的场景，因为每写一份数据，就要同步到集群中所有的节点上，如果节点数量多了，同步的开销还是很可观的。对于读数据，因为每个节点上都有缓存数据的拷贝，所以在replicated模式下的读可以充分利用所有节点的带宽，提供更好的读性能。而Partitioned模式更适合多写少读的场景，因为写数据时需要同步的节点数量要少，所以写性能更好。对于读场景，因为一份数据的拷贝只在集群的几台节点上，所以读性能势必会受影响。

配置缓存Replicated/Partitioned模式

好了，在了解完Ignite缓存不同的数据分片冗余策略后，让我们通过一个实际的例子看看如何在代码或是xml配置文件中配置不同的数据分片冗余策略。我们在上一篇文章的server节点代码上进行改造，大部分逻辑都保持不变，重点注意一下第26行~34行加入的新代码：

public class IgniteCacheOpModeExample {

    public static void main(String[] args) {

        Ignite ignite;

        // 创建一个TEST缓存并写入一些数据, key是城市的名字,value是省的名字

        IgniteCache<String, String> cityProvinceCache;

        if(args.length == 1 && !args[0].isEmpty())

        {

            //如果启动时指定了配置文件,则用指定的配置文件

            System.out.println("Use " + args[0] + " to start.");

            ignite = Ignition.start(args[0]);

            //配置文件中,我们将缓存设置为partitioned模式,backup数量为1

            cityProvinceCache = ignite.getOrCreateCache("TEST");

        }

        else

        {

            //如果启动时没指定配置文件,则生成一个配置文件

            System.out.println("Create an IgniteConfiguration to start.");

            TcpDiscoverySpi spi = new TcpDiscoverySpi();

            TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

            ipFinder.setMulticastGroup("224.0.0.251");

            spi.setIpFinder(ipFinder);

            IgniteConfiguration cfg = new IgniteConfiguration();

            cfg.setDiscoverySpi(spi);

            ignite = Ignition.start(cfg);

            CacheConfiguration<String, String> cacheCfg = new CacheConfiguration("TEST");

            // 如果不用配置文件启动,缓存模式被设置为replicated

            cacheCfg.setCacheMode(CacheMode.REPLICATED);

            /* 下面的配置将"TEST"缓存设为partitioned模式,并且设置了backup数量为1,这样保证即使有一个node出现

                故障的情况下,缓存数据还是完整可用的

            cacheCfg.setCacheMode(CacheMode.PARTITIONED);

            cacheCfg.setBackups(1);

             */

            cityProvinceCache = ignite.getOrCreateCache(cacheCfg);

        }

        cityProvinceCache.put("Edmonton", "Alberta");

        cityProvinceCache.put("Markham", "Ontario");

        cityProvinceCache.put("Montreal", "Quebec");

    }

}

在调用ignite.getOrCreateCache()函数之前，我们为"TEST"先生成一个CacheConfiguration，然后调用setCacheMode()将其模式设置为REPLICATED模式(在29~33行被注释掉的代码中，是如何设置PARTITIONED模式以及backups数量的代码)，最后再交由Ignite根据configuration生成"TEST"缓存。当然，和上一篇一样，也可以通过XML文件来配置缓存模式：

<beans xmlns="http://www.springframework.org/schema/beans"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

       xsi:schemaLocation="

       http://www.springframework.org/schema/beans

       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="grid.cfg" 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="224.0.0.251"/>

                    </bean>

                </property>

            </bean>

        </property>

        <property name="cacheConfiguration">

            <bean class="org.apache.ignite.configuration.CacheConfiguration">

                <!-- 设置缓存名字. -->

                <property name="name" value="TEST"/>

                <!-- 设置缓存模式. -->

                <property name="cacheMode" value="PARTITIONED"/>

                <property name="backups" value="1"/>

                <!-- 下面将缓存设置为replicated模式 -->

                <!--property name="cacheMode" value="REPLICATED"/-->

            </bean>

        </property>

    </bean>

</beans>

在XML文件中，我们加入了cacheConfiguration的配置，为了和代码里创建的缓存名字保持一致，配置里也使用了"TEST"作为缓存名字，"cacheMode"设为PARTITIONED，"backups"值设为了1(每个数据分片除了primay拷贝外，还有额外的一份backup拷贝，即缓存可以允许有一个节点故障而保证缓存数据的完整性)。

更新了代码和配置文件后，server节点如果制定了XML配置文件启动，生成的缓存为带一个backup的PARTITIONED模式，如果不用XML配置文件，则生成的缓存为REPLICATED模式。无论用哪种方式启动server节点，我们再重复这篇文章开头的那个实验，就会发现即使在一个节点失效的情况下，client节点还是可以访问到缓存中的所有数据，不会再出现丢数据的情况了。在实际使用过程中，正确的配置缓存的冗余模式直接影响到Ignite集群数据的高可用性。

总结

这篇文章我们介绍了Ignite集群中数据分片的不同冗余策略，在实际的使用过程中，不同的策略会直接影响集群中数据的高可用性和读写性能，所以理解不同的策略的优缺点，是使用好Ignite数据网格集群的第一步。 这篇文章里用到的例子的完整代码和maven工程可以在这里找到。 Server对应的xml配置文件在src/main/resources目录下。

下一篇，我们将继续了解一下Ignite针对不同的冗余策略提供的功能，比如数据分片由于节点失效出现丢失时的行为，primary拷贝和backup拷贝之前的同步等。