关于上游同一数据大批量重复推送问题处理

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/same-data-push.html

先粗略写，日后有缘完善

背景

上游系统在推送数据到下游系统时,由于网络、代码、又或者是运维上（主要是sql重推没去重之类的），导致上游短时间推送大量同一单号给到OMS系统，导致数据库压力剧增

解决方案

新增字段，Version，接收上游数据时先判断Version是否比OMS的大，如果大则更新，否则不更新

Other More

为什么不只用数据库锁版本号或者锁版本号？

先确认概念:

• Version（数据版本号,解决的是数据新旧问题）：

• version字段用于判断数据版本的新旧。在某些业务场景下，需要检查数据是否被其他操作修改过，以避免数据冲突或脏读的问题。通过比较version字段的值，可以判断当前数据是否是最新版本，如果版本不匹配，则可能意味着数据已被其他操作修改，需要采取相应的处理措施（如回滚、重新读取等）。

• lockVersion（乐观锁锁版本号,解决数据并发更新问题）：

• lockVersion字段用于乐观锁机制。乐观锁是一种并发控制的策略，通过在数据上加上一个版本号或时间戳，来实现对数据的并发修改控制。在更新数据时，会检查lockVersion字段的值是否与当前操作的期望值一致，如果一致，则允许更新操作，否则可能意味着数据已被其他操作修改，需要进行冲突处理（如回滚、抛出异常等）。

仅使用lockVersion字段在并发场景下，可能出现：
> - 由于lockVersion字段的值是在更新时才会更新，因此在更新前后，lockVersion字段的值是不变的。如果在更新前后，有其他操作修改了数据，那么lockVersion字段的值就会不一致，此时更新操作就会失败
仅使用Version字段在并发场景下，可能会出现：
> - 例如：A、B两个线程同时读取到version=1的数据，A线程将version更新为2，B线程将version更新为2，此时version=2的数据被更新了两次，这导致了其中一次更新被覆盖，数据版本不一致

先记录一些标签备忘

Version–>针对数据在业务上更新的版本号,对应上下游业务操作导致的一次更新，针对性的场景是:用户点击一次更新按钮
lockVersion–>针对系统内部的一次更新,不论是业务上,还是系统自己重试,每次更新都会更新lockVersion+1,针对性的场景是:重推