求大神解答一下一个小白程序员的疑惑

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1550 天前的主题，其中的信息可能已经有所发展或是发生改变。

今天跟我一位朋友讨论一个防止表单二次提交的问题，他是考虑用 redis，我的解决方案是在本地使用锁来保证请求在处理完成之前同一用户的其他请求会被忽略，代码如下：

private static final Set<String> LOCK_SET = new CopyOnWriteArraySet<>();

public String execute(){
...
    synchronized (this) {
        if (LOCK_SET.contains(uuid)) {
            return "failed";
        }
        LOCK_SET.add(uuid);
    }
...
}

然后就跟他杠上了，他的看法是当其他用户的请求来时会被锁住等待，用 redis 更快。
而我的看法是这个问题用 redis 有点太大材小用了，我认为在这个情况下等待锁的时间是远远小于连接 redis 的开销的。
有大神能帮忙解答一下吗，感激不尽。

17 条回复 • 2020-08-27 19:19:29 +08:00

IGJacklove

2020-08-27 13:30:45 +08:00

感觉 redis 不算大材吧...

Joezeo

2020-08-27 13:35:36 +08:00

@IGJacklove 主要我是感觉这个没有必要用 redis..

kop1989

2020-08-27 13:39:29 +08:00

我没太读懂。
redis 不是一个缓存技术么，只是作用于存储。

对于接口黑名单而言（二次提交也是黑名单，只不过是持续时间很短），不管用什么技术存储黑名单，锁是一定要存在的吧，所以不管用不用 redis，读取黑名单这步骤依然是要队列执行的。

kop1989

2020-08-27 13:41:19 +08:00

所以你们的争论其实就是 new 对象和用 redis 来存储黑名单的区别？

Immortal

2020-08-27 13:47:50 +08:00

早起还没有前后端分离的时候后端会在 form 里渲染一个 key 存在这个 key 并且和服务端一致才让提交
现在前后端分离了前端可以同样按这个思路客户端自己维护这个 key
这类解决方案 google 下很多的用 redis 啥的有点夸张了

Joezeo

2020-08-27 13:56:34 +08:00

@kop1989 emmm 差不多就是这个意思，我们争论的点就是在这个情况下有没有必要使用 redis 来进行存储

Joezeo

2020-08-27 13:59:15 +08:00

@Immortal 好的，感谢(我也是觉得这个用 redis 有点夸张了)

kop1989

2020-08-27 14:02:39 +08:00

@Joezeo #6 如果我理解的没错的话，那优缺点就很明显了。
直接 new 一个对象集合来存储是不可靠的，有可能被 web 容器的垃圾清理释放掉。
redis 相对安全，但 redis 的效率比直接 add 进集合再 remove 肯定是要慢很多。

但还是要强调下，这个话题和锁不锁无关，这种场景肯定是要有锁的，只不过 redis 是单线程，你不需要去操作锁而已。所以你同事说的啥“当其他用户的请求来时会被锁住等待”这个对 redis 也一样适用。

IGJacklove

2020-08-27 14:03:36 +08:00 via Android

@Joezeo 我感觉你锁接口比用 Redis 重的多，你的问题是单用户的重复提交，你的解决方案是锁全部人的提交。感觉你的问题不是更大吗？假如有一百个人的 200 个请求过来，你要做的就是拦住一百个人的后一百次重复提交，你的解决方案是锁了所有人的提交，这不是明显有问题吗？要是一百个人的一百次请求你根本不需要锁啊