这里我们只关注缓存，Ignite的设计中引入了很多的计算平台的能力，例如分布式计算和消息之类，在讨论其他框架时不做比较。
Ignite和Redis的差异
Ignite源于H2数据库，因此它的起点是个进程内缓存。但由于可以使用jdbc thin driver连接，加上它的集群特性，人们很容易把它当作一个进程外缓存去用，这是个误区。
官网quickstart对于Pythin/node的使用场景，应用使用thinclient的模式连接，这时候Ignite的作用和Redis就没有什么差异，Ignite .Net/c++有点特殊，可以使用linq的能力作为节点加入进来，也使用类似于java framework的完整能力，所以与其说Ignite是个中间件，不如说它是个framework。
数据结构方面，Ignite的数据结构比较简单，没有Redis丰富。
性能方面
Redis执行get的时间复杂度为O(1),和数据量大小无关,当数据量超过千万级别时，对于get操作非常友好。
Ignite的B+树结构导致get的时间复杂度和树高有关，不是O(1),当数据量较小时可以有不错的性能，随着数据量超过数百G时，get性能下降。但B+树帮助Ingite在执行query请求时，可以有较好的表现，优于redis的O(N)模式。
Ignite的进程内外的差别大约是10～20倍，需要注意适应场景。
几种场景下读缓存的大致性能如下：
redis:
remote:
serialize object: avergae time span = 669075
iginite:
local:
binary object: avergae time span = 2869
serialize object: avergae time span = 6295
remote:
binary object: avergae time span = 73911
serialize object: avergae time span = 82019
Ignite和ECache/Caffeine的差异
Iginite的集群特性是它区别于ECache/Caffeine等进程内缓存框架的最大区别，当我们需要对大型数据进行分片存储时会选择Ignite。ECache/Caffeine框架的使用一般不开启持久化，也不会产生序列化反序列化的计算，而Ignite由于是分布式框架，序列化是必备的能力。
合理选择缓存方式
Ignite最适用的场景是网格计算，特点是大规模的集群节点，节点需要高速的读缓存访问，且缓存的数据分布可以有一定的黏性（affinity）。由于数据分布有黏性，节点间数据在写入时需要一定的复制分发机制。
Ignite操作的对象往往需要按照class定义进行对象的序列化和反序列化操作，表达式求值，因此适用的场景以进程内操作为主，否则对应的bean需要被部署到其它节点上。具体做法是将实体类打包成普通jar包，并放在$IGNITE_HOME/libs/路径下面。注意：打包的时候不能打包成spring-boot的可执行包，要打包成普通jar包，这样相关类才能正常加载。当然如果集群里的节点均为应用节点，则可以不用考虑这个问题。
从上面可以看到Ignite的场景是比较专用的，很少作为通用缓存适用。
