时间：2021-07-01 10:21:17 帮助过：23人阅读
点赞控件不可能让用户每点击一次就发送一次ajax请求，一千人同时在线，我们不能保证这一千个用户都不是一些无聊的人。如果他们同时（哪怕不是同时）点着这个控件玩儿，服务器肯定会宕机狗带！那么问题来了，前端方面在原有点赞数字上肯定是加1或者减1。后端方面把点赞的用户id和点赞目标用户的数据库里面储存的点赞用户（平常我们都会看到谁点赞我）进行匹配，如果存在那就减一，不存在那就加一。但是这个时候我们不能强调数据一致性，除非用户刷新，如果强调数据一致性，我点个赞就加125，这个体验就不是很好。所以返回的还是原先用户看到的那个点赞数字加一或者减一，那这样就不可避免的每点击一次都要发送ajax请求了，服务器宕机指日可待。。。
有没有好的解决方案
业务场景：假设现在有1000人在同时浏览同一个微博，而且这一千人都将会点赞，为了简单化，我们假设这1000人是按照时间顺序依次点赞的。
点赞控件不可能让用户每点击一次就发送一次ajax请求，一千人同时在线，我们不能保证这一千个用户都不是一些无聊的人。如果他们同时（哪怕不是同时）点着这个控件玩儿，服务器肯定会宕机狗带！那么问题来了，前端方面在原有点赞数字上肯定是加1或者减1。后端方面把点赞的用户id和点赞目标用户的数据库里面储存的点赞用户（平常我们都会看到谁点赞我）进行匹配，如果存在那就减一，不存在那就加一。但是这个时候我们不能强调数据一致性，除非用户刷新，如果强调数据一致性，我点个赞就加125，这个体验就不是很好。所以返回的还是原先用户看到的那个点赞数字加一或者减一，那这样就不可避免的每点击一次都要发送ajax请求了，服务器宕机指日可待。。。
有没有好的解决方案
可以上redis，每日点赞存到redis里，用户点赞以及取消点赞操作的就是缓存中的内容，而不是数据库。然后在业务低峰时间(例如0:00) 再将每日最终点赞数写入数据库，这样的话每天只需要对数据库做一次数据写入就解决问题了
也想不到更好的法子,存储在redis是比较常规的做法,redis的操作都是原子性的,所以脏数据是不会产生的.
然后第二天就是数据持久问题,设定一个周期,定时将数据从redis往mysql跑一遍.
1、点赞请求储存的到队列（Redis RabbitMQ ZeroMQ etc.）
2、队列消费会根据业务系统压力判断是否把点赞刷入Mysql
3、当然是否点赞也需要两套逻辑判断
如果量真的很大的话，可以redis+消息队列更新，先把数据写入redis，然后用队列的方法慢慢存入数据库
我想了一个歪点子，不知道有用不：
在web端延迟发送ajax请求，比如，用户点击了一下点赞，然后js将点赞成功的样式展现出来（点赞数+1，显示点赞头像等），但并不立即发送ajax请求，等待10s（或者用户进行离开页面、刷新页面等操作时），如果中途没有再次进行点赞与取消点赞操作，再发送ajax请求，如果中途进行了点赞与取消点赞操作，那么重新计时延时！对于那些喜欢点一下赞就刷新一下再取消点赞的用户，只能跪着叫爹吧，哈哈哈！
点赞不是 live = live + 1吗？ “点个赞就加125”是什么意思？