2020-05-16：如何保证redis和mysql数据一致？

保证一致性的做法就是用某种分布式协议一致性来做：

1、SAGA或者TCC - 这两种需要业务代码的大量配合。通过业务代码来补偿一致性。

2、 现实当中有XA协议。比如Ehcache是支持XA协议的。但是性能表现不佳，运维也麻烦。

3、基于Paxos或者Raft的分布式锁，然后对Redis和DB进行双写

在XA事务中启用InnoDB支持两阶段提交，导致额外的磁盘刷新事务准备。 XA机制在内部使用，对于其二进制日志处于打开状态且正在接受来自多个线程的数据更改的任何服务器而言，都是必不可少的。如果您禁用了innodb_support_xa，那么事务可以以不同于实时数据库提交的顺序的方式写入二进制日志，当二进制日志在灾难恢复或复制从属环境中重播时，这可能会产生不同的数据。不要在复制主服务器上禁用innodb_support_xa，除非有异常的设置，只有一个线程可以更改数据。

对于仅从一个线程接受数据更改的服务器，这是安全的，建议禁用此选项以提高InnoDB表的性能。例如，您可以在只有复制SQL线程正在更改数据的复制从服务器上将其关闭。

使用xa进行测试时，对mysql进行了一些xa各阶段锁定试验，后来出现卡死情况就杀掉了线程，重启了mysql服务。重启后发现插入、修改数据都正常，但无法修改表结构，修改表结构就处于卡死状态，过一分多钟报超时错误。多次重启mysql服务后,问题依然如故.

查询innodb_trx表，发现有两个事务处于运行中。

SELECT * from information_schema.INNODB_TRX

2.方案2--xa rollback--不起作用

还有资料说，通过 xarecover 查看当前xa事务，然后回滚或提交。

针对上面的xa rollback我们也可以尝试用xa commit，问题一样不能解决（需要再次重启mysql才能运行，否则会找不到对应的xid）。

通过重启mysql后事务依然存在,我们大概推断应该跟redoundo有关系，xa事务异常后，mysql服务重启检测到了这两个事务就自动运行了，但因为未知原因，这两个事务并没有执行，一直处于running状态。

曾经试图研究mysql的redo undo机制或者对应的文件格式，但时间关系没有深入。

尝试能否打开对应的redo文件，对里面的语句进行修改，但网上找了资料没有合适的工具可以做这个事情。

一直很苦恼的思索解决办法，也咨询身边的一些朋友，对没有遇到过这方面的问题。

今天灵机一动，奔着大不了重新安装mysql的心态进行了破坏性的探索，当然前提要提前把数据备份出来。尝试停止mysql服务后，将mysql对应的datadir目录下几个文件删除掉，对应文件见下图。

然后重启mysql服务，曾担心启动失败的，但没想到mysql顺利的启动成功了，然后查看对应的表，发现一只running的事务终于消失了。

后续有时间我会继续深入分析其中的原理。

---