用Redis搞定数据排重，省时又高效，真心推荐试试这个方法

用Redis搞定数据排重，省时又高效，真心推荐试试这个方法 主要来自一位开发者在技术社区分享的亲身实践）

我记得特别清楚，那时候我们项目遇到一个特别头疼的问题，就是数据重复，简单说，就是我们有一个系统，每天要从外面接进来海量的数据，比如用户的注册信息啊、订单记录啊什么的，这些数据来源很多，难免会有重复的，比如同一个用户可能因为网络问题提交了两次,或者数据源自己就推送了重复的内容。

最开始，我们用的办法特“原始”，就是来了新数据，先去数据库里查一圈，用几个关键字段（比如用户ID加时间戳）拼成一个唯一键，去数据库里执行一个SELECT查询，看看是不是已经存在了，如果数据库里没有,我们再往里插入。

这办法听着挺合理是吧？但数据量小的时候还行，一旦数据量上来了，比如一天几百万甚至上千万条，完蛋了，数据库的压力巨大，每个数据进来都要查一次，数据库的CPU嗷嗷叫，磁盘IO也居高不下，最直接的结果就是，数据处理的速度越来越慢，数据积压得像小山一样，后面的数据要等很久才能被处理，业务那边天天催，我们这边天天加班“救火”。

我们也想过优化，比如给数据库字段加更复杂的联合索引，但效果不明显，而且索引本身也占空间，还会影响写入速度,那段时间真是焦头烂额。

后来，团队里有个同事提到了Redis，说可以用它来试试做排重，我们一开始还将信将疑，觉得Redis就是个缓存，能靠谱吗？但抱着死马当活马医的心态，我们决定试一下，这一试，真香！可以说是立竿见影。

我们是怎么用Redis做的呢？

其实思路特别简单，就是把那个“查重”的动作，从沉重的数据库身上,转移到速度超快的Redis内存数据库上。

我们不再每次去查询MySQL/Oracle了，而是用Redis的SET数据结构，Redis的SET有一个最大的特点，就是里面的元素都是唯一的，自动去重，我们就把那个用来判断是否重复的“唯一键”（用户ID_订单号”或者数据的MD5哈希值）直接当作一个元素,存到Redis的一个Set里面。

流程变成了这样：

1. 新数据来了。
2. 程序立马根据规则，生成一个唯一的“键”（比如计算一下这条数据的MD5码）。
3. 直接向Redis发起一个命令：SADD key_name 这个唯一键，这个SADD命令的作用是向集合里添加元素。
4. 关键点来了：Redis会帮我们自动判断。如果这个“唯一键”在Set里不存在，SADD命令会返回1，表示添加成功，说明这条数据是新的，如果这个“唯一键”已经存在了，SADD命令会返回0，表示添加失败，说明这条数据是重复的。
5. 我们的程序就根据这个返回值来判断：如果是1，就放行，继续后续处理（比如真正地写入业务数据库）；如果是0，就直接把这条重复数据丢弃掉,记录个日志完事。

你看，整个过程，我们完全绕开了传统数据库的查询，而Redis是基于内存的，读写速度极快，每秒处理几十万次这种简单的SADD操作跟玩儿似的，这样一来，处理速度的瓶颈一下子就打开了,数据积压的问题很快就解决了。

我们遇到的一些小问题和应对：

一开始也不是完全没顾虑,主要有两点：

第一，Redis是内存数据库，数据都在内存里，会不会不够用？ 确实，如果你把原始数据都存进去，那肯定不行，但我们存的不是完整数据，只是那个“唯一键”，可能就是一个几十字节的字符串，比如就算一天一千万条数据，每条键占50字节，总共也就500MB左右，对于现在的服务器内存来说，完全不是问题，我们甚至可以设置过期时间，比如只保留最近7天的排重键,这样内存就能循环利用。

第二，Redis万一重启或者宕机了，里面的排重数据不就全没了吗？ 这是个好问题，我们评估了一下业务场景，发现我们允许有极低概率的重复（比如宕机瞬间的少量数据，重复了也能接受，业务上可以容忍），如果业务要求100%精确不能重复，那可以开启Redis的持久化功能（AOF或RDF），这样即使重启，数据也能恢复，不过对于我们来说，为了极致性能，暂时没开持久化,也运行得很好。

用了之后的效果：

这么说吧，效果是颠覆性的，之前数据库服务器CPU长期在80%以上徘徊，用了Redis做排重后，数据库CPU直接降到了20%以下，变得非常轻盈，数据处理的速度从原来的每小时几万条，飙升到了每小时几百万条，再也没有积压的情况了，运维的同学不抱怨了，业务的同事也满意了,我们开发自己也终于能睡个安稳觉。

我现在逢人就说，如果你的系统也遇到了海量数据排重的问题，导致数据库压力山大，真的强烈推荐你试试Redis这个方案，它不是什么高深莫测的技术，就是用了Redis一个非常简单的特性，但恰恰解决了最关键的性能瓶颈，方法简单，效果显著，试错成本也低，绝对值得一试，这可以说是我过去一年里,做的性价比最高的一个技术改进了。