1、一個Ignite節點可以從命令行啟動，可以用默認的配置也可以傳遞一個配置文件。可以啟動很多很多的節點然后他們會自動地發現對方。
2、Ignite只需要一個ignite-core強依賴，通常你還需要添加ignite-spring，來做基於spring的XML配置，還有ignite-indexing,來做SQL查詢。
3、由於Ignite的零部署特性，當從IDE運行上面的程序時，遠程節點沒有經過顯示的部署，就獲得了計算作業。
4、導入獨立模塊。
ignite-spring：基於Spring的配置支持
ignite-indexing：SQL查詢和索引
ignite-geospatial：地理位置索引
ignite-hibernate：Hibernate集成
ignite-web：Web Session集群化
ignite-schedule：基於Cron的計划任務
ignite-log4j：Log4j日志
ignite-jcl：Apache Commons logging日志
ignite-jta：XA集成
ignite-hadoop2-integration：HDFS2.0集成
ignite-rest-http：HTTP REST請求
ignite-scalar：Ignite Scalar API
ignite-slf4j：SLF4J日志
ignite-ssh；SSH支持，遠程機器上啟動網格節點
ignite-urideploy：基於URI的部署
ignite-aws：AWS S3上的無縫集群發現
ignite-aop：網格支持AOP
ignite-visor-console：開源的命令行管理和監控工具
5、有時可能希望在Ignite節點啟動和停止的之前和之后執行特定的操作，這個可以通過實現LifecycleBean接口實現，然后在spring的配置文件中通過指定IgniteConfiguration的lifecycleBeans屬性實現。
6、支持的事件（這些事件也是可以被監聽的）
BEFORE_NODE_START：Ignite節點的啟動程序初始化之前調用
AFTER_NODE_START：Ignite節點啟動之后調用
BEFORE_NODE_STOP：Ignite節點的停止程序初始化之前調用
AFTER_NODE_STOP：Ignite節點停止之后調用
7、Ignite API中的所有分布式方法都既可以同步執行也可以異步執行。
8、IgniteAsyncSupport接口為很多Ignite API提供了異步模型，比如，IgniteCompute,IgniteServices,IgniteCache以及IgniteTransactions,都實現了IgniteAsyncSupport接口。
要啟用異步模式，需要調用withAsync()方法，他會返回同樣API的實例，這樣的話，異步功能就啟用了。
如果異步功能啟用了，實際的同步方法的返回值就被忽略了，異步操作中獲得返回值的唯一方式是通過future()方法。
9、Ignite有一個可選的概念，就是客戶端節點和服務器端節點，服務器節點參與緩存，計算，流式處理等等，而原生的客戶端節點提供了遠程連接服務器的能力。
10、當在Ignite中創建緩存時，不管是通過XML方式，還是通過Ignite.createCache(...)或者Ignite.getOrCreateCache(...)方法，Ignite會自動地在所有的服務端節點中部署分布式緩存。
11、IgniteCompute默認會在所有的服務端節點上執行作業，然而，也可以通過創建相應的集群組來選擇是只在服務端節點還是只在客戶端節點上執行作業。
12、要管理這些狀況（客戶端卡慢），可以配置允許向客戶端節點輸出消息的最大值，如果輸出隊列的大小超過此值，該客戶端節點會從集群斷開以防止拖慢整個集群。
13、Ignite的唯一特點是所有節點都是平等的。沒有master節點或者server節點，也沒有worker節點或者client節點，按照Ignite的觀點所有節點都是平等的。但是，開發者可以將節點配置成master，worker，或者client以及data節點。
所有集群節點啟動時都會自動將所有的環境和系統屬性注冊為節點的屬性，開發者也可以通過配置自定義節點屬性。
14、可以基於一些謂詞定義動態集群組，這個集群組只會包含符合該謂詞的節點。
下面是一個例子，一個集群組只會包括CPU利用率小於50%的節點，注意這個組里面的節點會隨着CPU負載的變化而改變。
15、很多系統選舉領導者通常要處理數據一致性，然后通常是通過收集集群成員的選票處理的。而在Ignite中，數據一致性是通過數據網格的類似功能處理的（Rendezvous Hashing或者HRW哈希），選擇領導者在傳統意義上的數據一致性，在數據網格以外就不是真的需要了。
然而，可能還是希望有一個協調員節點來處理某些任務，為了這個，Ignite允許在集群中自動地選擇最老的或者最新的節點。
16、Ignite中，通過DiscoverySpi節點可以彼此發現對方，Ignite提供了TcpDiscoverySpi作為DiscoverySpi的默認實現，它使用TCP/IP來作為節點發現的實現，可以配置成基於多播的或者基於靜態IP的。
17、Docker允許將Ignite應用及其所有的依賴打包進一個標准的容器，Docker會自動下載Ignite發布版，將代碼部署進Ignite以及配置節點，他還可以自動啟動配置好的Ignite節點,這樣的集成使只需要簡單地重啟Ignite Docker容器就可以部署新的節點。
18、Ignite數據網格支持本地、復制的、分區化的數據集，允許使用標准SQL語法方便地進行跨數據集查詢，同時還支持在內存數據中進行分布式SQL關聯。
19、Ignite實現了JCache(JSR107)規范（持久化存儲）。
20、Ignite提供了三種不同的緩存操作模式，分區、復制和本地。（三種各有優劣）
21、CacheWriteSynchronizationMode枚舉可以用來配置主節點和備份部分的同步和異步更新。
21、對於SQL查詢，Ignite提供了內存內的索引，因此所有的數據檢索都是非常快的，如果是在堆外內存中緩存數據的，那么查詢索引也會緩存在堆外內存中。
22、Ignite對SQL查詢的支持幾乎沒有任何限制，語法兼容於ANSI-99，可以使用任何SQL函數，聚合以及分組，Ignite會找出從哪里獲得查詢結果。（可以跨緩存查詢）
23、持續查詢對於當執行一個查詢之后希望持續地獲得該查詢結果數據更新的通知時，是很有用的。 持續查詢是通過ContinuousQuery類實現的
24、鑒於分區緩存是最常見的緩存數據的方式，那么數據和計算以及數據和數據的並置就可以顯著地提升性能和應用的可擴展性。
在許多情況下，如果不同的緩存鍵被同時訪問的話那么將他們並置在一起是很有利的。通常來說業務邏輯需要訪問不止一個的緩存鍵，通過將他們並置在一起可以確保所有的鍵具有緩存在同一個處理節點上的同一個affinityKey,從而避免從遠程節點獲取數據的昂貴網絡開銷。
例如，有一個Person和Company對象，然后希望將Person對象和其工作的Company對象並置在一起。對於一個鍵類型有兩種聲明關系鍵的方式。
25、雖然Ignite可以單獨地配置CacheRLoader和CacheWriter，但是在兩個單獨的類中實現事務化存儲是非常尷尬的，因為多個load和put操作需要在同一個事務中的同一個連接中共享狀態。為了緩解這個問題，Ignite提供了·org.apacche.ignite.cache.store.CacheStore·接口，他同時擴展了CacheLoader和CacheWriter。當希望通讀和通寫時，提供一個正常的緩存存儲的實現是很重要的。通讀意味着當緩存無效時會從持久化存儲中讀取，通寫意味着當緩存更新時會自動地進行持久化。所有的通讀和通寫都會參與整體的緩存事務以及作為一個整體提交或者回滾。
要配置通讀和通寫，需要實現CacheStore接口以及設置CacheConfiguration中cacheStoreFactory的readThrough和writeThrough屬性，下面的例子會有說明。
26、數據加載通常用於啟動時初始化緩存數據，用標准的緩存put(...)和putAll(...)操作通常加載大量的數據是比較低效的。數據流處理器是通過IgniteDataStreamerAPI定義的，他可以將大量的連續數據注入Ignite緩存。數據流處理器以可擴展和容錯的方式在數據被發送到集群節點之前通過把定量數據放在一起以獲得高性能。
數據流處理器可以用於任何時候將大量數據載入緩存，包括啟動時的預加載。
將大量數據載入緩存的另一個方法是通過CacheStore.loadCache()方法，他可以在不傳入要加載的所有鍵的情況下進行緩存的數據加載。
27、數據流處理器是通過IgniteDataStreamerAPI定義的，他可以往Ignite數據流緩存中注入大量的持續不斷的數據流，數據流處理器對於所有流入Ignite的數據以可擴展和容錯的方式提供了至少一次保證。
28、滑動窗口可以和任何其他Ignite緩存以同樣的方式進行查詢，可以使用基於謂詞的，基於SQL的和基於文本的查詢。
29、Ignite除了提供了標准的鍵-值的類似於Map的存儲以外，也提供了一個快速的分布式阻塞隊列和分布式集合的實現。
IgniteQueue和IgniteSet分別是java.util.concurrent.BlockingQueue和java.util.Set接口的實現，也支持java.util.Collection接口的所有功能，這兩個實現既可以以並置模式也可以以非並置模式創建。
30、分布式計算是通過以並行的方式執行來獲得高性能、低延遲和線性可擴展。Ignite計算網格提供了一套簡單的API，使得可以在集群內的多台計算機上執行分布式計算和數據處理。分布式並行處理是基於在任何集群節點集合上進行計算和執行然后將結果返回的能力實現的。
31、Ignite計算網格可以對集群或者集群組內的任何閉包進行廣播和負載平衡，包括純Java的runnables和callables。
32、ComputeTask是Ignite對於簡化內存內MapReduce的抽象，這個也非常接近於ForkJoin范式，純粹的MapReduce從來不是為了性能而設計，只適用於處理離線的批量業務處理(比如Hadoop MapReduce)。然而，當對內存內的數據進行計算時，實時性低延遲和高吞吐量通常具有更高的優先級。同樣，簡化API也變得非常重要。考慮到這一點，Ignite推出了ComputeTask API，它是一個輕量級的MapReduce(或ForkJoin)實現。
ComputeTask定義了要在集群內執行的作業以及這些作業到節點的映射，他還定義了如何處理作業的返回值(Reduce)。所有的IgniteCompute.execute(...)方法都會在集群上執行給定的任務，應用只需要實現ComputeTask接口的map(...)和reduce(...)方法即可。
33、每個任務執行時都會創建分布式任務會話，他是由ComputeTaskSession接口定義的。任務會話對於任務和其產生的所有作業都是可見的，因此一個作業或者一個任務設置的屬性也可以被其他的作業訪問。任務會話也可以在屬性設置或者等待屬性設置時接收通知。
34、通常來說在不同的計算作業或者不同的部署服務之間共享狀態是很有用的，為此Ignite在每個節點上提供了一個共享並發node-local-map。
IgniteCluster cluster = ignite.cluster();
ConcurrentMap<String, Integer> nodeLocalMap = cluster.nodeLocalMap():
35、Ignite支持作業的自動故障轉移，當一個節點崩潰時，作業會被轉移到其他可用節點再次執行。然而在Ignite中也可以將任何作業的結果認為是失敗的。工作的節點可以仍然是存活的，但是他運行在一個很低的CPU，I/O，磁盤空間等資源上，在很多情況下會導致應用的故障然后觸發一個故障的轉移。此外，也有選擇一個作業故障轉移到那個節點的功能，因為同一個應用內部不同的程序或者不同的計算也會是不同的。
36、負載平衡組件將作業在集群節點之間平衡分配。Ignite中負載平衡是通過LoadBalancingSpi獲得的。它控制所有節點的負載以及確保集群中的每個節點負載水平均衡。對於同質化環境中的同質化的任務，負載平衡采用的是隨機或者循環的策略。然而在很多其他場景中，特別是在一些不均勻的負載下，就需要更復雜的自適應負載平衡策略。
37、服務網格可以在集群上部署任意用戶定義的服務，比如自定義計數器，ID生成器，分層映射等。
Ignite可以控制每個集群節點應該部署多少個服務的實例，可以自動地確保所有的服務正確地部署和容錯。
所有的服務網格功能都是通過IgniteServices接口實現的。
38、Ignite分布式消息可以在集群內的所有節點間進行基於主題的通信，帶有特定消息主題的消息可以分布到訂閱了該主題的所有節點或者節點的子集。
Ignite消息基於發布-訂閱范式，發布者和訂閱者通過一個通用的主題連接在一起。當一個節點針對主題T發布了一個消息A，他會被分布到所有訂閱了主題T的節點。
39、gnite分布式事件功能使得在分布式集群環境下發生各種各樣事件時應用可以接收到通知。可以自動獲得比如任務執行、發生在本地或者遠程節點上的讀寫或者查詢操作的通知。
分布式事件功能是通過IgniteEvents接口提供的，可以通過如下方式從Ignite中獲得IgniteEvents的實例
40、Ignite會自動地對集群內發生的，作為緩存事件的結果生成的事件通知進行分組或者分批處理。
緩存內的每個事件都會導致一個事件通知被生成以及發送，對於緩存活動頻繁的系統，獲取每個事件的通知都將是網絡密集的，可能導致集群內緩存操作的性能下降。
Ignite中，事件通知可以被分組然后分批地或者定時地發送
41、Ignite提供了一個HTTP REST客戶端，可以以REST的方式通過HTTP或者HTTPS協議與集群進行通信。REST API可以用於執行不同的操作，比如從/對緩存的讀/寫，執行任務，獲取各種指標等等。
42、Ignite有一個獨特的功能，叫做Ignite文件系統（IGFS），就是一個分布式的內存文件系統，IGFS提供了和Hadoop HDFS類似的功能，但是只在內存中。事實上，除了他自己的API，IGFS還實現了Hadoop的文件系統API，可以透明地加入Hadoop或者Spark的運行環境。
43、Ignite Hadoop加速器提供了一個叫做IgniteHadoopFileSystem的Hadoop兼容IGFS實現，Hadoop可以以即插即用的形式運行在這個文件系統上，然后顯著地減少了I/O和改善了延遲和吞吐量。
優化：
1、Ignite有豐富的事件系統來向用戶通知各種各樣的事件，包括緩存的修改，退出，壓縮，拓撲的變化以及很多其他的。因為每秒鍾可能產生上千的事件，他會對系統產生額外的負載，這會導致顯著地性能下降。因此，強烈建議只有應用邏輯必要時才啟用這些事件。默認的話，事件通知是禁用的。
2、就大小和容量而言，Ignite的內部緩存映射行為非常像正常的Java HashMap。他有一些初始的容量（默認都非常小），是持有數據的兩倍，內部緩存映射的大小調整過程是CPU密集以及費時的，如果往緩存中加載大量的數據集（這是正常的使用場景），這個映射就會頻繁地調整大小。要避免這個問題，可以比對預期的數據集大小指定初始的緩存映射容量，這會在加載期間節約大量的CPU資源，因為映射不需要重新調整大小了。比如如果希望在緩存中加載一億的數據，可以用如下的配置：
3、如果使用了分區緩存，而且數據丟失並不是關鍵（比如，當有一個備份緩存存儲時），可以考慮禁用分區緩存的備份。當備份啟用時，緩存引擎會為每個條目維護一個遠程拷貝，這需要網絡交換和而且是耗時的。要禁用備份，可以使用如下的配置：
4、如果打算為了緩存數據為JVM分配大量的內存（通常大於10G的內存），那么應用很可能會遭遇長時間的GC暫停，他會顯著地增加延時。要避免GC暫停可以使用堆外內存來緩存數據-實際上數據仍然換存在內存中，但是JVM並不知道他而且GC也不起作用。要啟用不限大小的堆外存儲，可以使用如下的配置：
5、如果需要往緩存中加載大量的數據，可以使用IgniteDataStreamer來實現，數據流處理器在將數據發送到遠程節點之前會將數據正確地形成批次然后會正確地控制發生在每個節點的並發操作的數量來避免顛簸。通常他會比一堆單線程的操作有十倍的性能提升
6、如果能發送10個比較大的作業代替100個小些的作業，那么應該選擇發送大些的作業，這會降低網絡上傳輸作業的數量以及顯著地提升性能。對於緩存的條目也是同樣的問題-應該一直使用API方法，他會使用鍵和值的集合，而不是一個一個地傳遞。