数据双向复制中的6个数据冲突场景和解决思路

在双向复制，数据多活中，核心的一个部分就是数据处理，如何保证数据的如下几个问题，是整个方案设计的关键技术。

• 数据错乱
• 数据冲突
• 数据回环
• 数据一致性

数据错乱的部分主要是基于消息队列的处理内容，可以转化为基于消息队列的消息延迟，消息丢失，消息重复这几个场景进行细化。

其中数据回环的部分可以参考之前的一篇文章。

MySQL双主模式下是如何避免数据回环冲突的

在整个数据流转的过程中，如何处理数据冲突问题，我设定了如下的几个场景，欢迎留言补充。

场景1： INSERT导致的唯一性冲突

同步INSERT语句时违背了唯一性约束，例如双向同步的两个节点同时或者在极为接近的时间INSERT某一个主键值相同的记录，那么同步到对端时，会因为已经存在相同主键值的记录，导致Insert同步失败。

解决思路：

①　使用分布式ID的方案来规避，对于失败的写入，生成新的分布式ID重新应用

②　对于流水型数据，ID自增的方式，可以在写入时不解析id列，采用目标端和消费端的业务ID一致性

③　对于流行型数据，ID自增的方式，写入采用了id列的方式，可以生成新的异常域（比如9999999999开头的ID列）消费应用

场景2： 表结构不同步导致的数据写入失败

在表结构变更过程中，可能因为同步延时问题，出现部分字段，约束不一致导致的数据写入失败

解决思路：

①　表结构变更过程需要避免DML写入，新增字段如果不为空，需要考虑设置默认值

②　数据应用解析需要指定字段名和字段顺序

③　对于新增字段的操作，比如数据字段约束（如不为空）写入失败，需要重新修改JSON数据，重新推送消费

④　对于删除字段的操作，比如字段不一致导致写入失败，需要重新修改JSON数据，重新推送消费

场景3： 字段顺序不一致导致的数据写入失败

解决方法：

①　需要在初始化时维护两端的字段顺序，确保一致

②　通过后端的服务进行字段稽核，分为周期性或者主动监测

③　对于insert语句，在消费数据时，需要指定字段顺序

场景4：UPDATE更新的记录不完全匹配

1） UPDATE要更新的记录在同步目标实例中不存在

解决思路：数据操作转换为幂等SQL,转换为INSERT ON DUPLICATE模式

2） UPDATE要更新的记录出现主键或唯一键冲突

解决思路：

对于状态型数据，如果存在update操作中的唯一性冲突，需要对该记录进行持久化，并阻塞后续对于此记录的事务处理操作，结合业务场景进行分析

场景5： DELETE对应的记录不存在

DELETE要删除的记录在同步的目标实例中不存在。

解决思路：出现这种冲突时，不论配置何种冲突修复策略，可以选择忽略DELETE此类操作。

场景6：表不存在

对一些数据存在周期性管理，可能会触发drop类操作，导致两端的表结构信息丢失

解决思路：

①　对于状态型数据，如果存在DML操作失败，需要对该记录进行持久化，并阻塞后续对于此记录的事务处理操作，稍后结合业务场景进行分析

②　对于流水型数据，如果存在DML操作失败，需要对该记录进行持久化，不阻塞后续对于此记录的事务处理操作，稍后结合业务场景进行分析

在这个基础上，对于数据消费方案和一致性方案，我们在明天给出一些设计方案。