.net 集合分成几个等数量集合_Redis 的有序集合应用不当的大坑

最近因为一个投票项目的需求，为了在一定时间范围内限制用户的投票数量，我们采用了redis缓存用户投票总数和历史来达到限制用户在一定时间范围内的投票操作。

项目中我们采用redis的zset形式来保存用户的投票时间范围统计，score记录了用户id，value记录了用户的时间范围和当前已投票数。在测试过程中没有发现问题，上生产以后，一个巨大的坑出现了。当一个用户在一个时间范围内，达到投票限制，我们很好的达到了限制投票的需求。但是过了一会儿，该用户又可以继续投票了。经过检查生产和测试跟踪，发现当A用户的投票记录保存以后，达到限制值后，A用户不会再被允许投票。但是此时，当B用户也达到投票峰值后，A用户的投票统计记录消失了。此时就会出现A用户可以无限制刷票。

通过断点跟踪代码后我们发现，当B用户在相同时间范围的投票统计值和A用户相同时，A用户的记录就会被B用户干掉。后查询了Redis的相关ZSET特性说明，发现如下定义：

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

也就是说，当初想通过score记录用户唯一id来区分记录的方式是错误的。在Redis的ZSET中，score只能用来做自动排序，而不能作为唯一性键值。为解决此问题，我们在每个用户的value中，增加了用户的id，以保证value的唯一性。

至此，bug解决。但还有一个隐性漏洞，当score值由于某种极端情况，比如高并发情况下，系统可能会记录两个score值相同，但value值不同或相同的记录。这个问题留待有时间彻底解决一下。

总结这次填坑经历，还是对redis的一些特性不深知，所以给自己挖了大坑。后续要仔细研究一下。

本内容来自本人在CSDN的博客：https://blog.csdn.net/perlxs/article/details/103024967