posts/data-check/

[utterances-bot]

揭露数据不一致的利器 —— 实时核对系统

https://jiekun.dev/posts/data-check/

[Jun10ng]

太巧了，最近刚打算 改造 & 接入这个核对平台，结果在v站闲逛的时候，看到也是shopee的同事就点进来了，结果还是核对平台的作者。ORZ

[timeisgoing]

haha 我也搞过这个对账系统，这个系统逻辑简单，比较麻烦的是各种数据的适配接入

[Fungx]

博主您好，想请问下这种实时对账如何解决数据快速变更导致的误报呢？
比如对于某个值x：

1. 上游快速写入x=1,x=2，redis最终保存了x=2（x=1被覆盖）
2. 下游x=1变更到达redis，x=2变更还未执行
3. 进行检查：上游为x=2，下游为x=1，判断为不一致。

[jiekun]

Sorry 我想我去年没有留意到这条信息. 这个问题听起来非常有趣.

我不记得在系统中这是如何设计和解决的, 但是如果要我重新设计, 我会将原有的 Key - Value 数据结构修改为 Key - Linked List 数据结构, 也就是通过 Linked List 记录同一个 Key 的多个版本用于比较.

这个似乎会把系统变得更加复杂, 我认为当同一个 Key 对应的 Value (在还没被核对前就) 快速更改时, 应该提前识别到 "这个 Key 是有 Value 在缓存中的, 它还没经过校验" 然后再设计一些更加简化的方案.

至于是否要马上进行告警, 这取决于系统是否愿意容忍这种中间过程的不一致. 例如当某个 key 不一致, 我可以先记录, 并且过短暂 Interval 后二次检查, 如果它变得一致了, 有以下可能:

1. A 从原始值变成 1 再变成 2, B 也完全一致 (✓);
2. A 从原始值变成 1 再变成 2, B 直接从原始值变成 2 (??!!), 需要业务决定是否要告警;

确认了这些之后才能继续设计告警和告警抑制的方案.

[Jun10ng]

收到github的Watch提醒邮件，说下自己的看法。
在实际适合核对系统的时候，没遇到过需要核对x=1的场景，因为x=1，"1" 通常是中间态，类似pay pending等，而核对规则的触发通常配置在终态时触发，比如success时核对上下游的状态。

[jiekun]

@Jun10ng Wow 有趣的讨论, 这种情况确实是存在的, 中间状态可以不关注.

不过 @Fungx 提出的问题比较 General, 没有必要的上下文, 所以其实还是可以假定某些业务场景是需要状态严格按照比如 1->2->3 流转的, 然后需要核对系统确认是否上下游都严格遵循这个状态推进, 所以就需要能 "识别" 出 1->3 这种异常情况等等.

Anyways, 回复里都是不错的想法, 欢迎继续跟帖.

[zeming-coder]

有的数据不能确定终态 比如：优惠券的核销状态 随着订单的退款 重新下单等操作 优惠券的状态会在已核销 =》 未核销 =》 已核销……这个状态流中反复横跳，这个需要变化过程数据留痕才能够解决