第三方存储

本文是Ignite事务架构系列的最后一篇文章，在之前的文章中，讨论了与键值API的事务处理有关的一系列主题。 第一篇文章 中，主要介绍了二阶段提交协议及其工作方式； 第二篇文章 中，介绍了锁模型和隔离级别，介绍了悲观锁和乐观锁中不同隔离级别对应的消息流的细节，还介绍了死锁检测机制； 第三篇文章 中，介绍了故障和恢复机制，介绍了Ignite如何管理备份节点故障、主节点故障以及事务协调器节点故障； 第四篇文章 中，聚焦于原生持久化的事务处理，其中着重介绍了预写日志（WAL）和检查点； 在最后一部分，会聚焦于Ignite如何处理第三方持久化的事务。 通读和通写 Ignite的两个主要优势是扩展性和性能。Ignite遵循的一个基本原则是不撕裂不替换，换句话说，组织中的已有系统，正在支撑关键的业务且无法被轻易替换，但是可以通过更高的扩展性和性能来增强很多的业务查询，比如，Ignite可以提供内存数据网格服务（IMDG）或者在开启通读（当缓存中不存在时数据会从数据库中加载到IMDG）和通写（数据写入IMDG时也会持久化到数据库系统）时，为第三方数据库提供分布式缓存服务，如图1所示： 但是，事务必须妥善地处理，因为数据更新跨越了Ignite和第三方存储，维护IMDG和数据库之间的数据一致性就变得非常重要，为了达到这个目标，Ignite提供了CacheStore接口