数据同步一致性问题探讨

内部培训讲义精简

理解数据关系

区分关系和事实, 认识到关系的时效性

相关名词

为什么要做数据同步/关系冗余 ?

数据同步SLA

为什么要做增量同步?

增量同步的事件驱动来源

增量同步的流程复杂性

关系变更分类:

例子1: “筛选指定品类投放用素材”需求: 短路”素材-创意-广告-商品-品类”链路:

从监听商品识别品类关系变更角度来看:

  1. 商品新增品类识别: a. 顺流而上 顺着 商品-广告-创意-素材 链路找到关联的素材列表 b. 做素材-品类关系的增量更新
  2. 商品修改/删除品类识别: a. 同1-a步骤, 找到受到影响的素材列表 b. (逆流而下) 沿路返回: 素材-创意-广告-商品 找到这批素材所关联的所有商品的品类 c. 做素材-品类关系的覆盖更新

其他关系链路上也需要监听, 原因:

例子2: “文章(推广商品识别)品牌”筛选需求: 短路”文章-<带货>-商品, 商品-<识别>-品牌"链路:

增量同步套路总结

同步数据不一致/复杂性来源

  1. 没有处理变更/解除关系, 逆流而下覆盖更新
  2. 关系当事实, 没有监听变更
  3. 关系建立先后顺序做了错误假定

以上对于基础数据关系的期望:

  1. 发展健康稳定的关系: 只做关系新增, 不做关系变更/删除
  2. 保障关系链路建立的严格顺序性

很难!!!原因:

增量同步性能问题分析

一对多关系的扇入/扇出导致关系查询路径遍历数据量膨胀, 需要写入行数放大.

例: 3个主体2个关系, 单关系扇出/扇入上限10, 1行事件”顺流而上”影响100行, 再”逆流而下”影响10000行数据.

应对策略:

增量同步任务方针

代码逻辑

降低复杂性思路

(略)

数据存储方案选择

没有一种数据存储可以满足所有场景 避免试图用工具解释问题 (手里有锤子, 所有的问题都是钉子)

数据存储分野

结论

目前只是抛出数据同步问题, 暂无好的解决方案.

对策:

  1. 消灭问题, 不做数据同步, 查时关联
    • 针对特化的业务场景权衡决策
    • 如果需要冗余, 避免过于匹配业务具体需求的数据关系冗余, 做到满足性能的阶段, 保持一定的灵活性/预见性, 避免需求小变更导致大返工
    • 在数据同步维护的复杂性 和 查询复杂性 和性能SLA中找折衷
  2. 简单处理, 部分关系当作事实看待, 简单只做”顺流而上”, 但至少要认识到问题, 遇到问题时会解决, 遇到数据不一致问题显著时清楚要做”逆流而下”
  3. 直面惨淡的人生, 面对问题, 代码层面统一姿势, 降低目前解决严格一致数据同步脚本的复杂度/维护成本

“图穷匕见”说各组分工

(略)

HOME