思路
tomcat配置两个数据源，一个正常的mysql，一个ignite的server集群
如sit的数据需要变动，sit的tomcat会在往自身mysql中操作的同时，往ignite server集群中写入变动消息，往内存数据库中写入如本次变更的源环境，执行的语句等。
而在server集群中发生变动后，sit和uat的client监听端均取得server集群的变动（本次变更的源环境，执行的语句等），sit取到后，发现是变动的源环境就是自己，则不作处理；uat取得变动后，发现是变动的源环境不是是自己，则在自身的mysql进行相同操作，相当于SIT，所执行的语句在UAT同步进行了执行，即达到了数据同步
架构
采用独立式igntie集群，实现不同环境数据库同步
FAQ
1.ignite server集群如何搭建？
https://www.jianshu.com/p/640a90225923
配置文件：apache-ignite-fabric-2.2.0-bin/config/default-config.xml
注1：server端的client mode不用更改，保持默认即可
注2：集群中的server端的配置基本一致
2.server集群是否可以直接查询内存数据库？
可以使用 DBeaver或者直接使用sqlline命令行
https://www.zybuluo.com/liyuj/note/1023980
3. tomcat如何连接到ignite server集群？
在tomcat/conf/context.html中配置数据源即可
<Resource name="jndi/igniteDS"
auth="Container"
type="javax.sql.DataSource"
driverClassName="org.apache.ignite.IniteJdbcThinDriver"
url="jdbc:ignite:thin://xx.xx.xx.xx/"
>
4.client端如何搭建？如何配置client端与ignite server集群的连接？
客户端使用jar包形式启动，集成了ignite相关jar，设置了ignite.listen.clientmode=true, igntie.listen.ips=服务端的ip(s)，在src/main/java/xx/xx/xx/service/ignite/Application.java的ignite方法中以嵌入式模式的启动方式启动即可
配置文件：src/main/resource/(config/)application.properties
5. client端监听到的消息是什么格式？CQL是什么？
基于Ignite的ContinuousQuery
https://www.jianshu.com/p/e527af8213d0
CQL
持续查询语言（CQL, continuous query language）类似于:内存数据库+视图+触发器 的解决方案。
简单来说，一有符合条件的对象进入查询结果集，就执行一次回调函数。
6. 如何配置client端与mysql集群的连接？client端如何修改mysql中的数据？
使用spring boot框架的配置模式，在配置文件中配置好要连接的mysql后，执行与src/main/resource/mapper/下的xx.xml中的SQL语句即可在对应mysql中执行语句
配置文件：src/main/resource/(config/)application.properties
7. Ignite的持久化策略？
7.1.ignite原生持久化是一个分布式的ACID和兼容SQL的磁盘存储
7.2.磁盘上存储的数据集是内存中的数据集的超集。
7.3.和纯内存的使用场景一样，每个独立的节点只会持久化数据的一个子集，不管是主还是备节点，都是只包括节点所属的分区的数据。
7.4.持久化开启之后，所有的数据和索引都会存储在所有集群节点的内存和磁盘上，以类似的格式存储，避免在内存和磁盘之间移动数据时进行昂贵的转换。
7.5.如果整个集群宕掉，那么重启时是不需要通过从持久化预加载数据来对内存进行预热的，只要所有的节点都可以互相访问了，集群就具有了完整的功能。
7.6.开启了Ignite持久化，集群默认是未激活的，无法进行任何的CRUD操作。用户需要手工激活集群。
8.ignite的ACID实现？
ignite原生持久化的ACID的保证由2阶段提交协议（准备、提交阶段）、锁（悲观锁、乐观锁）以及ignite的故障恢复策略来保证
8.1.悲观锁：tx.get()/put()时就申请锁，阻止其他事务对数据的访问；乐观锁：tx.commit()时再申请锁，且不会阻止其他事务对数据的访问。
8.2执行tx.commit()方法时，先执行准备阶段，准备阶段失败会抛出异常，之后执行提交阶段。
8.3 ignite原生持久化的恢复策略由WAL（Write-Ahead Log预写日志）、检查点来保证。
8.3.1WAL的目的是以最快的速度向磁盘传播更新，以及为单个节点或者整个集群故障的场景提供一种恢复机制。值得一提的是，集群可以根据WAL的内容在故障或者重启时随时恢复到最近成功提交的事务。
8.3.2检查点解决了通过WAL从头到尾地恢复集群会花费大量的时间的问题，有助于通过在磁盘上保持页面的最新状态而高效地利用磁盘空间，并且允许在WAL档案中删除过时的WAL段（文件）。
注：Ignite没有纯粹的主节点或者备节点，每个节点默认既是主节点，又是备节点，它是一组分区的主节点又是其他分区的备节点。
参考
Apache Ignite（六）：Ignite的集群部署
https://my.oschina.net/liyuj/blog/651036
SQLLine 1.0.2
http://sqlline.sourceforge.net/#commands
持久化文档
https://www.zybuluo.com/liyuj/note/982784
Apache Ignite事务架构：2阶段提交协议
https://my.oschina.net/liyuj/blog/1626309
Apache Ignite事务架构：并发模型和隔离级别
https://my.oschina.net/liyuj/blog/1627248
Apache Ignite事务架构：故障和恢复