本文是Ignite事務架構系列的最後一篇文章，在之前的文章中，討論了與鍵值API的事務處理有關的一系列主題。
第一篇文章中，主要介紹了二階段提交協議及其工作方式；
第二篇文章中，介紹了鎖模型和隔離級別，介紹了悲觀鎖和樂觀鎖中不同隔離級別對應的消息流的細節，還介紹了死鎖檢測機制；
第三篇文章中，介紹了故障和恢復機制，介紹了Ignite如何管理備份節點故障、主節點故障以及事務協調器節點故障；
第四篇文章中，聚焦於原生持久化的事務處理，其中着重介紹了預寫日誌（WAL）和檢查點；
在最後一部分，會聚焦於Ignite如何處理第三方持久化的事務。
通讀和通寫
Ignite的兩個主要優勢是擴展性和性能。Ignite遵循的一個基本原則是不撕裂不替換，換句話說，組織中的已有系統，正在支撐關鍵的業務且無法被輕易替換，但是可以通過更高的擴展性和性能來增強很多的業務查詢，比如，Ignite可以提供內存數據網格服務（IMDG）或者在開啓通讀（當緩存中不存在時數據會從數據庫中加載到IMDG）和通寫（數據寫入IMDG時也會持久化到數據庫系統）時，爲第三方數據庫提供分佈式緩存服務，如圖1所示：
但是，事務必須妥善地處理，因爲數據更新跨越了Ignite和第三方存儲，維護IMDG和數據庫之間的數據一致性就變得非常重要，爲了達到這個目標，Ignite提供了CacheStore接口，爲通讀和通寫操作提供了完整的事務支持。
二階段提交
當Ignite使用第三方數據庫作爲持久化時，事務協調器會首先向第三方系統發送更新請求，然後再向集羣節點發送提交消息。事務化數據庫系統的工作方式提供了這樣的保證，因此，當數據庫事務失敗時，事務會被回滾，這樣緩存和數據庫仍然保持一致。
故障處理
因爲數據庫可以被視爲真實的數據源，所以管理故障要比之前討論的場景要簡單得多。數據總是可以從數據庫重新加載到緩存以保證一致性，如圖2所示，這對所有場景都有效，包括事務協調器故障的場景。Ignite的CacheStore接口提供了從數據庫批量加載到緩存的功能，這就提供了一個快速恢復緩存的方法。
總結
處理第三方數據庫存儲的事務故障比之前討論的其他場景要簡單得多，因爲更新和修改首先被應用於第三方存儲。