5分鐘內讓你瞭解Apache Ignite - softwaremill

• 分割槽意味著資料透過key分佈在節點上，例如MongoDB中的分片，或Kafka和Cassandra中的分割槽。分割槽快取是處理大型資料集且頻繁更新的理想選擇。
• 複製 是在每個節點上儲存所有資料，對於快取記憶體讀取比快取記憶體寫入要頻繁得多且資料集較小的情況，此模式是理想的。

Ignite本機永續性是一種分散式ACID和SQL相容的磁碟儲存，可透明地與Ignite的永續性記憶體整合。點燃永續性是可選的，可以開啟和關閉。禁用後，Ignite將成為純記憶體儲存。
這裡的本機意味著它內建在專案中，而不是e依賴Ignit的外部解決方案。

Apache Ignite最常見的用例是什麼？

記憶體資料網格
為了應對快速寫入，我們可以將Apache Cassandra用作資料儲存，而要實現快速隨機讀取，我們可以將Apache Ignite用作記憶體中的資料網格。

分散式key-value儲存
與資料網格類似，它是記憶體中的快取層。它實現了JCache規範（JSR 107），實現了對位於同一位置的資料（位於同一節點上）的計算，並執行連續查詢以通知客戶端資料更新。
一個很好的例子是將Ignite用作HTTP會話儲存實現。

數字整合中心
再次類似於資料網格，Ignite跨多個資料儲存，可以查詢，因為它將是一個統一的共享資料儲存。
假設您有幾個RDBMS，例如MySQL，PostgreSQL和Oracle DB，並且希望將它們作為一個可查詢的資料庫公開在一起。但是請注意表連線：它們將在Ignite記憶體中進行，因此所有必需的資料都將首先載入到Ignite記憶體中。
同樣，所有寫入操作都必須透過Apache Ignite進行，以防止記憶體中的內容與底層資料儲存之間的不一致。

用於高效能運算
遵循MapReduce正規化的計算可以在共置資料上執行。由於對記憶體和一個節點中載入的資料進行了計算，因此可以實現高效能。不需要透過網路進行資料改組和磁碟I / O操作。

共享給Apache Spark
將資料載入到記憶體中並將其作為RDD提供給Spark可以提高Spark應用程式的效能。

Apache Ignite與CAP定理？
與其他分散式系統（如Apache Kafka或Cassandra）類似，可以將Apache Ignite配置為實現更高的可用性（AP）或放棄可用性以確保一致性（CP）。
儘管文件中還不清晰，，但是配置如何影響可用性或一致性，但是我在郵件列表中發現了以下語句：

[i]當群集丟失分割槽的所有副本時，行為由[url=https://apacheignite.readme.io/docs/partition-loss-policies]PartitionLossPolicy[/url]定義。當前預設值為IGNORE，它的確是AP而不是CP選項。您可以將其設定為READ_WRITE_SAFE或READ_ONLY_SAFE以獲取CP行為。[/i]

.…您可以將一個或多個鍵上的多個快取操作分組為一個邏輯操作，稱為事務。這些操作將在沒有對指定鍵進行任何其他交錯操作的情況下執行，並且將全部成功或全部失敗。沒有部分執行操作。

透過2PC（兩階段提交協議）支援完整的ACID事務，但是如果僅在一個節點上執行事務，則使用重量更輕的版本1PC。
一個ATOMIC原子性在另一方面操作執行一次為多個業務之一。
這些原子性模式是在客戶端級別配置的，並且可能因呼叫而異。
在此TRANSACTIONAL模式下，支援兩種鎖定策略-悲觀鎖定和樂觀鎖定。在悲觀鎖定中，超時觸發器將檢測死鎖。但是，客戶端的責任是始終以相同的順序獲取鎖，並使獲取的鎖的數量保持較低，並按節點對它們進行排序以減少網路流量。
使用樂觀鎖，在讀取過程中會記錄版本號，在寫入時會將其與當前版本進行比較。在版本不匹配時，事務將回滾。
最後一個有趣的提示：如果在多個Ignite節點之間使用分散式事務，則在第二階段中，一個節點可能無法提交，因此必須手動回滾該事務。那是2PC的樂趣。
此外，當一個資料儲存完成提交併在第二個資料儲存完成提交之前將其提供給客戶端時，基礎資料儲存之間可能會發生不一致。如果第二次提交失敗，則第一個提交不會自動回滾。

腦裂
當發生網路分割槽時，就會發生裂腦情況。您最終有兩個叢集，必須決定要做什麼。接受請求並最終在節點之間恢復一致性（解決衝突）？還是禁用其中一個群集？
Apache Ignite有一些解決此問題的方法。
一種基於TCP / IP發現和基準拓撲，其中在分割槽的情況下，當分割槽固定後，兩個群集將不再形成一個群集。這樣可以防止資料被覆蓋。但是，您有責任拆除並重新啟動排除的節點，以便它們可以追上倖存的節點。同樣，如果兩個不相交的群集獲得同一金鑰的更新，則這些衝突的更改需要手動解決。
另一種裂腦解決策略是基於Zookeeper Discovery的。每個節點都知道群集拓撲。如果某個節點發現無法聯絡另一個節點，則會向Zookeeper投訴。Zookeeper擁有拓撲的全域性概述，還提供有關誰可以看到誰的資料，並且可以透過告訴哪些節點保留在叢集中以及哪些節點被排除在如何做出明智的決定上，從而決定如何解析網路分割槽。

GitHub上還有一個外掛，以及GridGain的商業裂腦解析器。

流函式

流是關於將資料移至Ignite，執行轉換並對該資料進行連續查詢。
流分批執行。它們按節點分組。這意味著，一個節點的批處理可以比另一個節點的傳送更早，儘管一些訊息到達較晚，但完成了該批處理，因為第一個仍在等待更多訊息。換句話說，不保留排序。
由於批次可能會失敗並重新交付，因此流式傳輸至少可以保證交付一次。因此，您必須在覆蓋或忽略鍵值（已存在）之間進行選擇。同樣，第二批也不會等到第一批成功交付後再進行。因此，也不會保留特定節點內的排序。
透過Kafka聯結器可以使用Kafka進行流的匯入匯出。

什麼是Apache Ignite替代品或競爭產品？
與Apache Ignite相似，Hazelcast也被宣傳為記憶體計算平臺。同樣，它與SQL資料庫整合，但不支援事務。

Redisson，用於Redis的Java客戶端還設有一個記憶體中資料網格。
在分析方面，Druid中提供了類似的功能。儘管支援連線，但僅限於較小的查詢表。
最後但並非最不重要的一點是，Infinispan被宣傳為具有兩個主要用例（例如快取或資料網格）的記憶體中資料儲存。
總而言之，當需要執行復雜的SQL操作時，Apache Ignite似乎會發光。否則，替代工具可能會更好。