Apache Ignite事務架構：第三方持久化的事務處理

本文是Ignite事務架構系列的最後一篇文章，在以前的文章中，討論了與鍵值API的事務處理有關的一系列主題。

第一篇文章中，主要介紹了二階段提交協議及其工做方式；

第二篇文章中，介紹了鎖模型和隔離級別，介紹了悲觀鎖和樂觀鎖中不一樣隔離級別對應的消息流的細節，還介紹了死鎖檢測機制；

第三篇文章中，介紹了故障和恢復機制，介紹了Ignite如何管理備份節點故障、主節點故障以及事務協調器節點故障；

第四篇文章中，聚焦於原生持久化的事務處理，其中着重介紹了預寫日誌（WAL）和檢查點；

在最後一部分，會聚焦於Ignite如何處理第三方持久化的事務。

通讀和通寫

Ignite的兩個主要優點是擴展性和性能。Ignite遵循的一個基本原則是不撕裂不替換，換句話說，組織中的已有系統，正在支撐關鍵的業務且沒法被輕易替換，可是能夠經過更高的擴展性和性能來加強不少的業務查詢，好比，Ignite能夠提供內存數據網格服務（IMDG）或者在開啓通讀（當緩存中不存在時數據會從數據庫中加載到IMDG）和通寫（數據寫入IMDG時也會持久化到數據庫系統）時，爲第三方數據庫提供分佈式緩存服務，如圖1所示：

可是，事務必須妥善地處理，由於數據更新跨越了Ignite和第三方存儲，維護IMDG和數據庫之間的數據一致性就變得很是重要，爲了達到這個目標，Ignite提供了CacheStore接口，爲通讀和通寫操做提供了完整的事務支持。

二階段提交

當Ignite使用第三方數據庫做爲持久化時，事務協調器會首先向第三方系統發送更新請求，而後再向集羣節點發送提交消息。事務化數據庫系統的工做方式提供了這樣的保證，所以，當數據庫事務失敗時，事務會被回滾，這樣緩存和數據庫仍然保持一致。

故障處理

由於數據庫能夠被視爲真實的數據源，因此管理故障要比以前討論的場景要簡單得多。數據老是能夠從數據庫從新加載到緩存以保證一致性，如圖2所示，這對全部場景都有效，包括事務協調器故障的場景。Ignite的CacheStore接口提供了從數據庫批量加載到緩存的功能，這就提供了一個快速恢復緩存的方法。

總結

處理第三方數據庫存儲的事務故障比以前討論的其餘場景要簡單得多，由於更新和修改首先被應用於第三方存儲。