微服务中什么是脏写？怎样引起的，有何危害，如何解决脏写。

事务隔离机制是怎么解决脏写、脏读、不可重复读和幻读的

MySQL 是支持多个事务并发执行的。有的事务写、有的事务读，这种读写冲突是有可能发生脏写、脏读、不可重复读和幻读问题的。

在可重复读这个隔离级别下，它会在事务开启的时候，把值都记下来，以后读的时候，就读原来记下来的值就可以了。就像我们写代码的时候。

准确来说就是，如微服务中的Seate事务，为了保证事务的 原子性（一组数据只能成功只能失败，其他什么也做不了 。）

AT 模式如何做到对业务的无侵入 ：
一阶段：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数
据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，
在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

为什么 after images 要和 数据库数据 进行比较呢？？

脏写就是在这里容易出现，因为read uncommitted（读未提交）的after是未来的数据，但可能会被其他线程发生的事务把现有的数据给更改了，那么就不能保证事务的一致性了，数据进入了脏东西被修改了。所以我们会将after数据和现有数据相比较，看看是否在发生错误决策回滚期间，被强先进入了脏东西。

其实，有脏东西写入是有其他事务的执行，是！为了保护其他线程发生的事务的提交的原子性。这种脏东西（原本不脏），在原子性的规则中，不能被第一时间判断是否是成功还是失败的东西。介入了别人要来回滚的数据，你要等别人回滚了后在（脏写）写进去就不是脏写了。

意思就是：别人小两口闹矛盾还没有正式分手，你就去勾搭女生，你不是脏男你是什么？？别人分手了，那你去勾搭她，那你就不是脏男了。