Heim > Artikel > Backend-Entwicklung > 我有个点赞功能的逻辑实现,性能优化,高并发的问题想问
业务场景:假设现在有1000人在同时浏览同一个微博,而且这一千人都将会点赞,为了简单化,我们假设这1000人是按照时间顺序依次点赞的。
点赞控件不可能让用户每点击一次就发送一次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”是什么意思?