关于黑马点评的面试问题

是这样的，技术不是说一个好一个不好，技术是需要选择的，通常选择一个技术会解决另外一个技术的问题但也带来了新的问题。正如上述，使用 redis 实现点赞，是因为点赞可以疯狂点击，需要较高响应速度，redis 基于内存很好的实现这点，但是呢，随着点赞这个 key 的增大，会占用很多内存，引起新的大 key 问题，正如 MySQL 大库问题需要分库分表思想一样，大 key 问题也可以拆分成多个小 key，或者说客户端限制大 key 请求，尽量只请求大 key 中的一部分数据...如此深入去思考，会发现技术是做不到完美的，只会在带来一部分优点的同时也带来一部分缺点。

点赞排行榜也可以用MySQL，不过你要顾及到性能问题、写入延迟、数据一致性等问题，其实在点赞方面还是比较建议考虑使用缓存； 如果使用Redis，确实会占用较多的内存。如果关注内存的使用情况，可以考虑以下两种方案来减少内存占用： 1.用Redis的Bitmaps数据结构来保存点赞详情。然后从Bitmaps的数据结构角度向面试官阐述如何解决内存占用，这里简单说一下，Bitmaps是以位的形式存储数据，可以有效地压缩存储空间。 2.使用Redis的HyperLogLog数据结构来统计点赞数量。 如果点赞数量非常庞大，可能会导致内存占用过大。优化的方案可以从下面几点来考虑： 1.使用redis分片集群，实现分布式存储，将点赞信息分散到多个Redis节点上，减轻单个节点的负载压力。 2.设置合理的过期时间或定期清理过期的点赞数据（因为其实对于一个点赞详细来说，我们应该进行取舍，其实前端页面只需要展示部分数据，要么保存最新的一批点赞详情，要么保存一批最旧的--也就是最先点赞的人），避免占用过多的内存空间。 这是大致的一些思路吧，正如一楼老哥说的，技术不是说一个好一个不好，技术是需要选择的，通常选择一个技术会解决另外一个技术的问题但也带来了新的问题，我认为面试官抛出这么一个问题其实要的是我们的思路，在面试中如果有一个比较好的思路并分开深入阐述它的原理，我认为对于面试来说也是一个不错的加分点。 个人瞥见，如有问题，也请指出，多谢。

m

m

m

m

m

m

m

m

m

m

m

M

m

m

m

m

m

m