本文是Ignite事务架构系列的最后一篇文章，在之前的文章中，讨论了与键值API的事务处理有关的一系列主题。

中，主要介绍了二阶段提交协议及其工作方式；

中，介绍了锁模型和隔离级别，介绍了悲观锁和乐观锁中不同隔离级别对应的消息流的细节，还介绍了死锁检测机制；

中，介绍了故障和恢复机制，介绍了Ignite如何管理备份节点故障、主节点故障以及事务协调器节点故障；

中，聚焦于原生持久化的事务处理，其中着重介绍了预写日志（WAL）和检查点；

在最后一部分，会聚焦于Ignite如何处理第三方持久化的事务。

通读和通写

Ignite的两个主要优势是扩展性和性能。Ignite遵循的一个基本原则是不撕裂不替换，换句话说，组织中的已有系统，正在支撑关键的业务且无法被轻易替换，但是可以通过更高的扩展性和性能来增强很多的业务查询，比如，Ignite可以提供内存数据网格服务（IMDG）或者在开启通读（当缓存中不存在时数据会从数据库中加载到IMDG）和通写（数据写入IMDG时也会持久化到数据库系统）时，为第三方数据库提供分布式缓存服务，如图1所示：

但是，事务必须妥善地处理，因为数据更新跨越了Ignite和第三方存储，维护IMDG和数据库之间的数据一致性就变得非常重要，为了达到这个目标，Ignite提供了CacheStore接口，为通读和通写操作提供了完整的事务支持。

二阶段提交

当Ignite使用第三方数据库作为持久化时，事务协调器会首先向第三方系统发送更新请求，然后再向集群节点发送提交消息。事务化数据库系统的工作方式提供了这样的保证，因此，当数据库事务失败时，事务会被回滚，这样缓存和数据库仍然保持一致。

故障处理

因为数据库可以被视为真实的数据源，所以管理故障要比之前讨论的场景要简单得多。数据总是可以从数据库重新加载到缓存以保证一致性，如图2所示，这对所有场景都有效，包括事务协调器故障的场景。Ignite的CacheStore接口提供了从数据库批量加载到缓存的功能，这就提供了一个快速恢复缓存的方法。

总结

处理第三方数据库存储的事务故障比之前讨论的其他场景要简单得多，因为更新和修改首先被应用于第三方存储。