对于 评论 发送,出现网络延迟、响应慢,用户多次点击发送按钮,怎么解决只生成一次数据存入DB

深渊向深渊呼唤

场景描述:

当你对一篇文章点击发送评论的时候,如果网络延迟,响应速度慢,页面停留在发送评论的页面,这时候你以为没有发送成功,疯狂的点击发送/提交按钮,结果后台服务器短时间内接收到大量的重复数据,该怎么处理?

可能的解决方案

前端控制:

    禁用按钮的形式

用户编写评论内容之后,点击提交,修改CSS样式(比如按钮设置为disabled禁用)。修改css样式消耗网络资源很小,可以快速的修改。直到后台数据响应完成之后,将css样式改回。

    清空评论内容,发送评论时为空则提示不发送。

用户编写评论点击提交,马上清空评论内容,再次点击发送按钮,进行评论内容为空不能发送提示。

    防抖、节流

设置定时器,设置时间,在这个时间段内的多次点击,就清空计时器,重新计时,直到计时器计时满足设置的时间,才发送请求。

    延迟、排队

发送请求之后,直到后台处理完成,并返回结果,才能继续发送请求,在这个时间段内发送的请求都拦截不进行处理或排队去重再发送。

后端控制:
5. 幂等(判断内容重复)

所谓的幂等就是多次的重复处理,结果应该不变。也就是对于同一个评论的多次提交,结果不变(只有一次结果是成功的),也就是如果内容重复,只保存一条记录到DB。
常用的两种方式:
1)建立唯一索引,防止新增脏数据
可以限制重复插入数据,当重复时,数据库会抛异常,保证不会出现脏数据。但体验很不好,并且实用场景有限制。
2)利用 token 机制,防止页面重复提交
核心思想是为每一次操作生成一个唯一性的凭证,也就是token。一个token在操作的每一个阶段只有一次执行权,一旦执行成功则保存执行结果。对重复的请求,返回同一个结果。、

    频率控制

比如对于每篇文章进行评论,60秒以内只能进行一次评论,60秒内发送多条评论只保留第一条存入数据库。

    分布式锁

在进入方法时,先去获取锁,如果获取到锁,就继续执行后面的流程。否则,就等待锁的释放一直到获取到锁。当执行完方法时,释放锁。【注意】锁要设个超时时间,防止意外没有释放到锁。
它可以用来解决分布式系统的幂等性,常用的实现方案是 redis 和 zookeeper 等工具。

栏目