在Java后端面试中，面试题：如何设计一个支撑百万并发的点赞系统是高频考察的高并发场景题，它不仅能考察求职者对高并发架构设计的掌握程度，还能看穿对业务场景的理解深度——比如是否兼顾数据一致性、用户体验和成本控制。鳄鱼java社区的面试数据显示，能完整拆解业务痛点并给出落地方案的求职者，高并发相关岗位的通过率比只会说“用Redis”的高70%。
一、先拆解面试题背后的业务痛点与考察点
面试官抛出这个题，本质上是想考察你对三个核心矛盾的平衡能力，而非单纯的技术选型： 1. 高并发读写冲突：热门内容（如明星动态、爆款商品）可能每秒产生几万次点赞请求，单节点服务无法支撑百万级并发； 2. 数据一致性要求：不能重复计数、点赞状态要与实际操作一致，同时要兼顾最终一致性与实时性； 3. 成本与体验的平衡：既要保证用户点击点赞后秒级反馈，又要避免过度依赖昂贵的Redis资源，控制架构成本。 鳄鱼java社区的面试导师强调：很多求职者开口就说“用Redis存点赞数”，但忽略了“怎么防止重复点赞”“Redis宕机后怎么办”等细节，这会让面试官觉得你只懂表层技术，缺乏业务思维。
二、分层架构设计：从百万并发到落地的核心链路
要支撑百万并发，必须采用分层架构拆解压力，每个层级负责单一职责，形成“接入层-服务层-缓存层-持久层”的完整链路： 1. 接入层：Nginx限流与负载均衡：用Nginx做第一道防线，通过漏桶算法限制单用户每分钟10次点赞，同时用负载均衡将请求分发到多个服务实例；鳄鱼java的实战数据显示，合理的限流能将无效请求（如刷赞）降低60%，减少后端压力。 2. 服务层：分布式微服务集群：用Spring Cloud或Dubbo搭建服务集群，每个实例独立处理请求，避免单点故障；同时将点赞服务与核心业务服务解耦，避免点赞流量影响订单、商品等核心链路。 3. 缓存层：Redis Cluster热点处理：用Redis Cluster做缓存层，分为两个部分：①用Redis Hash存点赞计数（key为"like:article:123"，field为"count"，value为点赞数），利用Redis incrby操作的原子性实现高并发计数；②用Redis Set存已点赞用户ID（key为"like:article:123:users"），判断用户是否已点赞，防止重复计数。Redis Cluster单分片可支撑10万QPS，10个分片即可轻松覆盖百万并发场景。 4. 持久层：MySQL异步同步最终一致：用MySQL存储点赞的最终数据，通过Kafka等MQ异步将Redis的计数同步到MySQL，避免高频写入阻塞业务流程；同时给MySQL表添加唯一索引（user_id + article_id），作为防重复点赞的最后一道防线。
三、核心细节处理：解决面试官可能追问的问题
回答【面试题：如何设计一个支撑百万并发的点赞系统】时，面试官必然会追问细节，以下是高频问题的解决方案： 1. 怎么防止重复点赞？：采用“Redis Set前置校验 + MySQL唯一索引兜底”的方案，用户点赞时先判断Redis Set中是否存在用户ID，不存在则执行SADD和incrby操作，同时异步写入MySQL，即使Redis出现异常，MySQL的唯一索引也能防止重复写入。 2. Redis宕机后怎么办？：用本地缓存（如Caffeine）兜底，当Redis不可用时，返回本地缓存的点赞数，同时触发告警，后台异步从MySQL加载数据恢复Redis缓存；另外开启Redis的RDB+AOF持久化，避免数据丢失。 3. 热点内容的缓存击穿怎么处理？：将热门内容的点赞缓存标记为“热点缓存”，单独分配Redis分片，避免热点流量挤占其他缓存资源；同时给热点缓存设置永不过期，后台定时更新计数。 4. 点赞数实时更新影响性能怎么处理？：采用“异步同步 + 最终一致”的策略，Redis计数实时更新，用户点击后秒级反馈，而MySQL的计数每5分钟同步一次，或当计数变化超过100次时同步一次，减少MySQL的写入压力。
四、性能调优：将并发能力再提升300%
基础架构搭建完成后，通过以下调优可进一步提升并发能力： 1. 异步化削峰：用Kafka将点赞请求异步化，用户点击点赞后，先将请求写入Kafka，再由消费线程处理Redis和MySQL的写入，避免直接阻塞请求响应；鳄鱼java的测试数据显示，异步化后，服务的QPS提升了200%。 2. 序列化优化：用Protobuf代替JSON作为Redis的数据序列化方式，Protobuf的序列化体积比JSON小60%，Redis的吞吐量可提升150%。 3. 热点隔离：将热门内容（点赞数超过10万）的点赞缓存单独分到一个Redis集群，避免热点流量影响普通内容的缓存服务；同时采用“读写分离”，用Redis主节点处理写入，从节点处理读取，提升读取性能。 4. 连接池优化：将Redis连接池的最大连接数设置为2000，最小空闲连接设置为200，避免连接耗尽或频繁创建连接的开销。
五、面试应答技巧：怎么组织语言拿满分
在面试中回答这个题时，要遵循“痛点→架构→细节→调优”的逻辑，避免零散地说技术名词： 示例应答：“面试官您好，设计支撑百万并发的点赞系统，首先要处理三个核心痛点：高并发读写、数据一致性、成本控制。我会采用分层架构：接入层用Nginx限流和负载均衡，服务层用Spring Cloud集群，缓存层用Redis Cluster存点赞计数和用户ID，持久层用MySQL异步同步。核心细节上，用Redis Set防重复点赞，MQ异步同步计数，Redis宕机时用本地缓存兜底。性能调优上，用异步化和热点隔离提升并发能力。我在鳄鱼java社区的百万并发实战项目中，参与过类似的点赞系统设计，当时我们用Redis Cluster支撑了每秒15万次的点赞请求，异步同步到MySQL的延迟控制在10分钟以内。”
六、总结与思考
回答【面试题：如何设计一个支撑百万并发的点赞系统】的核心，不是堆砌技术名词，而是平衡“性能、一致性、成本”三者的关系——既要用Redis满足高并发需求，又要用MySQL保证数据最终一致，还要通过限流、异步化控制成本。鳄鱼java社区的实战经验告诉我们，高并发架构设计从来不是“用最先进的技术”，而是“用最适合业务的技术”。
最后，不妨思考一个延伸问题：除了技术架构，你还能从业务角度优化点赞系统吗？比如根据用户的活跃度调整点赞的缓存策略，或者用AI预测热门内容提前预热缓存？这些思考能让你在面试中脱颖而出，展现超越技术的业务思维。
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
