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

[houOne]

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

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

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

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

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

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

[2020beBetter]

1.入口 对客户发来的码包进行逐条验证，与历史数据比较。
2.出口 对包装盒喷涂完成后进行验证，这个成本较大（可以考虑进行部分验证）

[tool2d]

"2. 有一个码管理系统，条码都会导入系统，然后通过系统生成 txt 文件 下发给喷码机。"

既然能拿到原始数据，何必用摄像头识别二维码。txt 就直接过滤了。

[lenmore]

没必要 redis 。几千万数据，建好索引，MySQL 没有任何问题。

[yshtcn]

码包是客户给的没关系，你在喷码之前就查重就可以了。虽然帖子比较乱，不知道是历史查重还是同一包查重。但是只要你把码给解析成数据，那就是个查重算法解决的问题。

[yshtcn]

可以说不需要任何的数据库或者高并发，实习生/GPT 都会写

[yshtcn]

昂，其实楼主已经做了，是我没认真看。其实问题已经转化为一批/一个新的数据如何在每批几十万，累计千万的数据库中查重的问题了。一批的话，我觉得速度不是问题。但是单个再校验就要求速度了。
我认为 GPT 提出的结合哈希表（散列表）或者布隆过滤器、数据库索引优化应该就可以了。最多会出现假阳性的检测结果。

[unco020511]

@stinkytofu 拿到码包第一时间就可以去重啊,为啥还要到最后的流程去重

[dode]

历史条码严格递增，不允许变小

[dode]

按二维码的前缀或后缀分库分表，压缩包复制 N 份，各自解压按分表规则导入查重

[tek]

md5 + hash

[lmshl]

如果不能改变上游的话，最简单的方法就是搞一个 bloom filter index ，postgresql 原生支持这种 index 。
如果只能用 mysql 的话，也可以在 mysql 里自己维护实现 bloom filter ，不是很难。
然后做分级索引，合并成一个大的 bloom 。

虽然会有 false positive ，只要控制在 1%以内，你就可以以极高的效率查出哪个码从来没出现过。仅在命中 bloom 的时候去做二次校检。

[rekulas]

这个直接分表不是很简单么,mysql 一表一亿基本几毫秒就返回了

其实更好的方式是找个 kv 库, 不需要 redis 直接本地磁盘就行了, 1 年亿级数据太小了压根不用担心效率,一天 1 亿的数据库对 kv 来说也没啥影响

提供个参考, 之前 rocketdb, 40 亿数据情况下普通 ssh 硬盘读取查询 5-10 万并发,平均时间几毫秒

[sgwk]

你这个系统做的时候就有问题，这是 20 多年前的会这么做，现在不会这么做的。

[houOne]

@sgwk 请教一下 现在会怎么做呢？

[sgwk]

生成二维码的时候，用算法，根本就不会重复了。我们目前在用的防伪，溯源就是这样的。

[houOne]

@sgwk #35 保证生成的二维码数据唯一，这个没有什么问题。但是把二维码数据用于人工参与的生产制作喷码环节时 有可能重复，或者有批次概念的二维码产品打包等操作，要对产品上的二维码再做校验检查。我想了解一下，后面这部分的技术如何实现。

[sgwk]

@godloveplay 私下聊吧 c2d3azY2Ng==