来讲点原有的改造吧。 黑马点评有旧有的点赞系统，它是通过redis的Zset集合简单实现的。每次更新的时候更新数据库。但如果在高并发下，每一个用户点赞就要更新一次数据库，数据库的压力会非常大，崩掉也很正常。首先用户点赞后，采用redis自带的原子命令将点赞数更新，之后更新数据库。并发情况下更新数据库需要消息队列异步更新，采用批量消息执行和批量插入，将多次点赞执行消息一次插入执行，并做好补偿机制，保障消息任务执行失败的场景。 而在查询点赞排行榜的时候，若缓存失效了，此时查询数据库更新缓存。正常流程是先查库再重建缓存，但要考虑到高并发的影响防止将数据库打崩。第一步当前请求发现缓存失效，需要上分布式锁，要进行双重锁校验，之后推荐发送异步消息至消息队列进行重建缓存的逻辑，不建议当前请求重构缓存。之后当前请求可以等待正常的少量时间，返回更新后缓存中的值。若缓存迟迟未建立，推荐返回默认页面。