版权声明:本文为博主原创文章,转载请附上博文链接! https://blog.csdn.net/woson_wang/article/details/89315309
Otter同步延迟导致数据库反查(补充)
在上一篇文章中,谈到Otter中出现反查会带来的问题 Otter同步延迟导致数据库反查(使用Otter遇到的问题二),在查看了代码后(DatabaseExtractor.java)发现反查中存在多层的判断。
本篇为对于双向同步出现问题的推测,不作为最终的结论
条件
代码如下:
if (flag && (eventData.getEventType().isInsert() || eventData.getEventType().isUpdate())) {// 判断是否需要反查
Future future = completionService.submit(new DatabaseExtractWorker(pipeline, item), null); // 提交进行并行查询
if (future.isDone()) {
// 立即判断一次,因为使用了CallerRun可能当场跑出结果,针对有异常时快速响应,而不是等跑完所有的才抛异常
try {
future.get();
} catch (InterruptedException e) {
cancel(futures);// 取消完之后立马退出
throw new ExtractException(e);
} catch (ExecutionException e) {
cancel(futures); // 取消完之后立马退出
throw new ExtractException(e);
}
}
futures.add(future);// 记录一下添加的任务
}
可以看出进行了判断:
if (flag && (eventData.getEventType().isInsert() || eventData.getEventType().isUpdate()))
flag
代码如下:
boolean flag = mustDb || (eventData.getSyncConsistency() != null && eventData.getSyncConsistency().isMedia());
对于mustDb:
boolean mustDb = pipeline.getParameters().getSyncConsistency().isMedia();
public boolean isMedia() {
return this.equals(SyncConsistency.MEDIA);
}
public static enum SyncConsistency {
/** 基于当前介质最新数据 */
MEDIA("M"),
/** 基于当前的store记录的数据 */
STORE("S"),
/** 基于当前的变更value,最终一致性 */
BASE("B");
...
}
若关闭数据库反查,channel配置如图:
此时查看数据库的配置:
mysql> select * from otter.channel;
...
{"channelId":116,"enableRemedy":false,"remedyAlgorithm":"LOOPBACK","remedyDelayThresoldForMedia":60,"syncConsistency":"BASE","syncMode":"FIELD"}
...
得到:
- enableRemedy=‘false’,则mustDb同样为false。
- (eventData.getSyncConsistency() != null
- eventData.getSyncConsistency().isMedia()) = false
即flag=false。
.
(eventData.getEventType().isInsert()
判断是否为INSERT
.
eventData.getEventType().isUpdate()))
判断是否为UPDATE
.
综上可得,当变更的类型为UPDATE时,就一定会触发数据库反查
.
.
反查导致的问题
在发生的数据库反查时,若配置了主站点,则在反查时,就会进行update的覆盖。具体变现为: