互联网大厂java求职者面试

原创于 2025-06-08 09:17:13 发布 · 725 阅读

8 ·

CC 4.0 BY-SA版权

##############阁下如果是抄袭，爬取文章作恶或误导他人的开发者,请阅读中国现行法律的相关处罚条例再动手，转载之前最好先验证#############

文章标签：

#java #八股文 #面试 #求职 #Java

Java场景面试宝典专栏收录该内容

1071 篇文章

订阅专栏

📕我是廖志伟，一名Java开发工程师，清华大学出版社签约作家、Java领域优质创作者、优快云博客专家、阿里云专家博主、51CTO专家博主、产品软文专业写手、技术文章评审老师、技术类问卷调查设计师、幕后大佬社区创始人、开源项目贡献者。

📙拥有多年一线研发和团队管理经验，研究过主流框架的底层源码(Spring、SpringBoot、SpringMVC、SpringCloud、Mybatis、Dubbo、Zookeeper)，消息中间件底层架构原理(RabbitMQ、RocketMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。

📘不定期分享高并发、高可用、高性能、微服务、分布式、海量数据、性能调优、云原生、项目管理、产品思维、技术选型、架构设计、求职面试、副业思维、个人成长等内容。

Java程序员廖志伟

第一轮：流量洪峰下的生存法则

面试官（架构组负责人张涛）："你在简历中提到设计过日均10亿次调用的订单系统。假设大促期间瞬时下单量突破50万QPS，系统出现数据库连接池耗尽告警，此时从技术链角度应该如何破局？"

廖志伟："首先，我会通过APM工具查看慢查询，看是否存在未命中索引的全表扫描，比如优惠券核销时的JOIN操作。接着，我会检查线程池配置，如果默认连接数是200，当突发流量达到300%时会触发拒绝策略。最后，我会排查是否存在事务泄漏，特别是@Transactional注解嵌套使用时容易引发长事务。"

面试官："明白了，那么假设确认是真实流量冲击，如何在不扩容的情况下保障核心链路？"

廖志伟："我会启动三级熔断预案。首先是客户端动态降级，对非VIP用户隐藏促销弹窗。其次是网关层熔断，基于Sentinel的热点参数限流，针对SKU维度。最后是服务层隔离，将库存预扣服务迁移到独立线程池，避免拖垮整个Tomcat。"

第二轮：连环故障的蝴蝶效应

面试官："限流后客服反馈大量用户投诉付款失败，日志显示分布式锁超时，此时如何定位？"

廖志伟："这涉及到Redisson看门狗机制的失效场景。我会检查GC日志，如果发生Full GC导致STW超时，锁会被误释放。同时，我会排查网络分区风险，ZooKeeper临时节点的心跳检测是否受交换机抖动影响。还有时钟漂移问题，NTP服务器同步间隔过大导致锁提前过期。"

面试官："如果改用etcd实现分布式锁，与Redis方案相比有何优劣？"

廖志伟："etcd基于Raft协议具有强一致性优势，但相应延迟增加。写入性能方面，Redis单节点10w+/s vs etcd集群1w+/s。适用场景上，etcd适合配置管理，Redis适合高频次锁竞争。容灾成本方面，etcd需要奇数节点部署，运维复杂度更高。"

第三轮：技术决策的哲学思考

面试官："你在技术方案中多次强调最终一致性，如果财务要求资金操作必须强一致，如何处理？"

廖志伟："这需要分层设计。核心交易层采用TCC模式+事务状态表，外围业务层使用MQ事务消息+本地事件表，对账补偿层建立定时核对任务，修复状态不一致。但要注意CAP的权衡，强一致必然导致可用性下降。"

面试官："如果产品坚持要为了用户体验放弃数据准确性，作为架构师如何应对？"

廖志伟："这需要建立技术红线意识。用生产故障案例教育团队，设计双层验收机制，架构评审委员会+核心业务SLA公示，开发降级演练工具，例如ChaosBlade模拟数据不一致场景。"

第四轮：数据一致性保障

面试官："在分布式系统中，如何保证数据的一致性？"

廖志伟："在分布式系统中，保证数据一致性通常有几种策略：强一致性、最终一致性和会话一致性。强一致性要求所有节点在同一时间看到相同的数据，最终一致性允许短暂的数据不一致，但最终会达到一致。会话一致性则要求在同一个会话中看到的数据是一致的。具体选择哪种策略，需要根据业务需求和系统特点来定。"

面试官："那么，在分布式事务中，如何解决数据一致性问题？"

廖志伟："分布式事务通常采用两阶段提交（2PC）和三阶段提交（3PC）协议来解决数据一致性问题。2PC将事务分为准备阶段和提交阶段，确保所有参与节点在提交前达成一致。3PC在2PC的基础上增加了预提交阶段，进一步减少阻塞。但2PC和3PC都有其缺点，如性能瓶颈、单点故障等，所以还可以考虑其他方案，如TCC（Try-Confirm-Cancel）模式、SAGA模式等。"

第五轮：分布式事务解决方案

面试官："TCC模式在分布式事务中有什么优势？"

廖志伟："TCC模式将分布式事务拆分为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。在尝试阶段，业务操作被尝试执行，如果成功，则进入确认阶段进行最终提交；如果失败，则进入取消阶段进行回滚。TCC模式的优势在于，它允许局部事务失败时进行局部回滚，从而提高系统的容错性和可用性。"

面试官："SAGA模式与TCC模式相比，有哪些不同？"

廖志伟："SAGA模式是一种基于事件驱动的事务模式，将一个大事务拆分为多个小事务，每个小事务完成后触发下一个小事务。SAGA模式的优势在于，它允许在某个小事务失败时进行补偿操作，从而保证整个事务的最终一致性。与TCC模式相比，SAGA模式更加灵活，但实现起来相对复杂。"

第六轮：分布式缓存一致性

面试官："在分布式系统中，如何保证缓存的一致性？"

廖志伟："保证分布式缓存的一致性通常有几种策略：缓存穿透、缓存击穿和缓存雪崩。缓存穿透是指缓存和数据库中都没有数据，导致请求直接打到数据库上；缓存击穿是指热点数据过期，导致大量请求直接打到数据库上；缓存雪崩是指缓存中大量数据同时过期，导致请求直接打到数据库上。针对这些情况，可以采用以下策略：设置热点数据永不过期、使用分布式锁或缓存穿透策略、设置合理的过期时间、使用缓存预热策略等。"

面试官："Redisson和Redisson Cluster如何保证缓存一致性？"

廖志伟："Redisson和Redisson Cluster都是基于Redis的分布式缓存解决方案。Redisson通过实现分布式锁、分布式集合、分布式计数器等数据结构，保证了缓存的一致性。Redisson Cluster通过分片和复制机制，实现了数据的高可用性和一致性。具体来说，Redisson Cluster通过Raft协议保证了数据的一致性，通过分片保证了数据的分布性。"

第七轮：分布式消息队列

面试官："在分布式系统中，如何选择合适的消息队列？"

廖志伟："选择合适的消息队列需要考虑以下因素：性能、可靠性、可扩展性、易用性等。常见的消息队列有Kafka、RabbitMQ、ActiveMQ等。Kafka适合高吞吐量的场景，RabbitMQ适合复杂的业务场景，ActiveMQ适合中小型应用。具体选择哪种消息队列，需要根据业务需求和系统特点来定。"

面试官："Kafka和RabbitMQ在分布式消息队列中有什么区别？"

廖志伟："Kafka和RabbitMQ在分布式消息队列中有以下区别：Kafka是基于发布/订阅模式的分布式消息队列，具有高吞吐量、可扩展性等特点；RabbitMQ是基于AMQP协议的分布式消息队列，具有可靠性、易用性等特点。Kafka适合处理大规模的数据流，RabbitMQ适合处理复杂的业务场景。"

第八轮：分布式存储

面试官："在分布式系统中，如何选择合适的分布式存储方案？"

廖志伟："选择合适的分布式存储方案需要考虑以下因素：性能、可靠性、可扩展性、易用性等。常见的分布式存储方案有HDFS、Cassandra、MongoDB等。HDFS适合大数据场景，Cassandra适合高并发场景，MongoDB适合文档型数据库场景。具体选择哪种分布式存储方案，需要根据业务需求和系统特点来定。"

面试官："HDFS和Cassandra在分布式存储中有什么区别？"

廖志伟："HDFS和Cassandra在分布式存储中有以下区别：HDFS是一种分布式文件系统，适用于存储大规模数据集，具有高可靠性、高吞吐量等特点；Cassandra是一种分布式NoSQL数据库，适用于高并发场景，具有高可用性、高性能等特点。HDFS适合存储大文件，Cassandra适合存储小文件。"

第九轮：分布式搜索引擎

面试官："在分布式系统中，如何选择合适的分布式搜索引擎？"

廖志伟："选择合适的分布式搜索引擎需要考虑以下因素：性能、可靠性、可扩展性、易用性等。常见的分布式搜索引擎有Elasticsearch、Solr等。Elasticsearch具有高吞吐量、可扩展性等特点；Solr具有易用性、可定制性等特点。具体选择哪种分布式搜索引擎，需要根据业务需求和系统特点来定。"

面试官："Elasticsearch和Solr在分布式搜索引擎中有什么区别？"

廖志伟："Elasticsearch和Solr在分布式搜索引擎中有以下区别：Elasticsearch是一种基于Lucene的分布式搜索引擎，具有高吞吐量、可扩展性等特点；Solr是一种基于Lucene的分布式搜索引擎，具有易用性、可定制性等特点。Elasticsearch适合处理大规模数据，Solr适合处理复杂查询。"

第十轮：分布式计算框架

面试官："在分布式系统中，如何选择合适的分布式计算框架？"

廖志伟："选择合适的分布式计算框架需要考虑以下因素：性能、可靠性、可扩展性、易用性等。常见的分布式计算框架有Spark、Flink等。Spark具有高吞吐量、易用性等特点；Flink具有高可靠性、实时性等特点。具体选择哪种分布式计算框架，需要根据业务需求和系统特点来定。"

优快云