根据ip,设备号或者什么唯一标识去判断点赞的唯一性,更新用缓存比如redis,然后异步同步写入到数据库中,如果异步通知点赞人,就将点击当成事件放到一个队列中 统一处理即可。
锁住点赞,点赞发送请求的时候,锁住点赞按钮,不让用户点击
直接回馈用户点赞,用户对于这种很简单的操作很多细节难以感知到,为了更佳的用户体验可以在点赞的时候,直接把web的样式显示+1,然后发送请求给后端。我们这边一般的点赞操作都是这样:
+=============+ +----------------------------------+ | 用户点赞 | ----> | 直接回馈用户点赞成功 | | | <---- | 样式+1 | +=============+ +----------------------------------+ | | 异步发送点赞请求 -----------------------> 后端接收,数据库完成点赞
这就是并发啊,不可能把类似这样的情景全部去掉,引入缓存就好了,当然你可以适当的做点全局手段,每秒点击量超过多少就给个警告,类似防一些爬虫,单个IP单位时间内有点击上限
点赞后去掉按钮
控制点击次数,次数过多,提醒
根据ip,设备号或者什么唯一标识去判断点赞的唯一性,更新用缓存比如redis,然后异步同步写入到数据库中,如果异步通知点赞人,就将点击当成事件放到一个队列中 统一处理即可。
锁住点赞,点赞发送请求的时候,锁住点赞按钮,不让用户点击
直接回馈用户点赞,用户对于这种很简单的操作很多细节难以感知到,为了更佳的用户体验可以在点赞的时候,直接把web的样式显示+1,然后发送请求给后端。
我们这边一般的点赞操作都是这样:
这就是并发啊,不可能把类似这样的情景全部去掉,引入缓存就好了,当然你可以适当的做点全局手段,每秒点击量超过多少就给个警告,类似防一些爬虫,单个IP单位时间内有点击上限
点赞后去掉按钮
控制点击次数,次数过多,提醒