请问厂里面一物一码的二维码重复校验，一般怎么做？

老板要做一个二维码去重的功能。我们厂生产的每个包装盒上都会喷上一个唯一的二维码，为了防止二维码重复，计划在流水线上加装摄像头进行数据采集。

目前构想是这样的：每个托盘有 200 个盒子，二维码朝上采集一板货可能分 4 个区域采集。一次会有 50 个二维码上传到服务器进行校验，如果发现有重复的二维码，服务器会返回重复的二维码，然后设备会对重复的盒子定位并标记。

每批货物有一个码包，每个码包有 50 万个二维码。如果考虑历史码包，数据量可能会更大。

码包是客户用加密压缩文件给的，之前的系统是，收到条码之后导入 mysql 数据，用临时表校验重复，数据库用一段时间就变得贼大，要定时删历史数据。不用考虑剔除，所以对校验时长没有要求。

我有两个问题想请教大家：

如果只对几个码包进行验重，千万数量级的二维码，使用 Redis 是否可行？
如果需要考虑历史码包进行验重，有没有什么好的方案？能保证验重接口的响应时间在 3 秒以内？

xjpicism

57 天前

布隆过滤器？

aliyun2017

57 天前

对于第一个问题，使用 Redis 可行。Redis 是一个高性能的键值存储系统，可以用于缓存、数据结构存储和消息传递等多种场景。在你的情况下，可以使用 Redis 来存储已经验证过的二维码，通过对已存储的二维码进行对比来判断是否重复。Redis 的速度非常快，适合处理大量的数据。你可以将每个二维码作为键存储在 Redis 中，当需要进行校验时，通过查询 Redis 来判断二维码是否重复。这样可以有效地减少数据库的负载，提高验证的效率。

对于第二个问题，如果需要考虑历史码包进行验重，并且要求响应时间在 3 秒以内，可以考虑使用分布式数据库和查询优化等技术来处理。以下是一种可能的方案：

1 、使用分布式数据库，如 Apache HBase 、Cassandra 或 MongoDB ，来存储历史码包的数据。这些数据库可以水平扩展，具有良好的查询性能和高可用性，适合处理大规模数据。

2 、对于历史码包的验重，可以将数据分片存储在不同的节点上，避免单一节点的负载过重。并采用合适的数据建模和索引设计，以提高查询的效率。

3 、使用查询优化技术，如索引、分区、缓存等，来提高查询的性能。通过合理的查询计划和数据存储方式，可以减少查询的响应时间。

4 、可以考虑使用异步处理和批量处理的方式，将二维码的验证任务分解为多个子任务进行处理，以提高整体的处理效率。例如，可以将待验证的二维码按批次发送到后台进行验证，再将验证结果返回给前端。

总的来说，使用分布式数据库和查询优化等技术，结合合理的数据存储和查询策略，可以满足对历史码包进行验重并保证响应时间在 3 秒以内的需求。具体的方案可以根据你的具体业务和技术要求进行进一步的调研和评估

aliyun2017

57 天前

@aliyun2017 来自 Ai 回复

tomSoSleepy

57 天前

转成数学题问问 AI?

vus520

57 天前

1. 千万级的数据 redis 完全可以，直接使用 hash 或者 kv 就可以搞定，不要使用 bitmap
2. 不知道具体逻辑，在 redis 场景内，验重接口超过 500ms 就算慢了

edward1987

57 天前

如果 redis 成本过高，用 mongodb 的 uniq key 插入也是可以的一般 1s 内就能返回

tool2d

57 天前

千万数量级的二维码，听起来很唬人，其实就是一堆 int 整形数字去重算法。

本地内存建立一个 hash 表去重，都能直接搞定。

ytmsdy

57 天前

我觉得还不如直接修改修改二维码生成算法来的方便，时间戳搞成毫秒级别，我就不信这还能再重复了！

jgh004

57 天前

数据存到 san 上，服务器内存搞大点，条码表建索引，千万级别很快的，亿级也没事。

lmshl

57 天前

把二维码的位数搞大一点，比如 128-bit 不就不会重复了么？🤔
为啥要设计的这么复杂？
UUID 也就 128-bit, 100 万亿 UUID 中重复一次的概率是百万分之一。
买双色球都没中过头奖，不如直接用 UUID 编码到二维码了

BeiChuanAlex

57 天前

为什么要查重，直接用时间+随机数生成不就行了

xulihang

57 天前

扫码用的是什么库？扫这么多码准确吗

xyfan

57 天前

为什么不在喷二维码之前进行校验，要生产完成之后流水线加摄像头，这不是舍近求远吗？
你们的二维码是自己的算法生成的吗？是的话加一个时间戳\年月日\自增的生产批号相关的项不就能直接保证不重复。如果二维码是客户给的，你们只负责喷印，也应该在喷印之前对数据进行去重，效率应该更高。