互联网大厂java求职者面试

我是廖志伟

于 2025-06-06 06:55:03 发布

阅读量550

点赞数 20

分类专栏： Java场景面试宝典文章标签： java 八股文面试求职 Java

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

本文链接：https://blog.youkuaiyun.com/Java_programmer_liao/article/details/148462884

版权

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

151 篇文章

订阅专栏

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

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

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

Java程序员廖志伟

个人编著书籍

《Java项目实战——深入理解大型互联网企业通用技术》（基础篇）：简体字版链接、繁体字版链接

《Java项目实战——深入理解大型互联网企业通用技术》（进阶篇）：https://item.jd.com/14616418.html

《Java项目实战——深入理解大型互联网企业通用技术》（架构篇）：待上架

《解密程序员的思维密码--沟通、演讲、思考的实践》：待上架

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

面试官（架构组负责人张涛）："廖志伟，你在简历中提到设计过日均10亿次调用的订单系统。那我们得聊聊，假设在双11大促期间，瞬时下单量突破了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，而etcd集群大约是1w+/s。适用场景上，etcd适合配置管理，Redis适合高频次锁竞争。容灾成本上，etcd需要奇数节点部署，运维复杂度更高。"

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

面试官："你在技术方案中多次强调最终一致性，但如果财务要求资金操作必须强一致，我们该怎么办？"

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

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

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

第四轮：数据一致性的权衡

面试官："廖志伟，你在前面提到CAP定理，但实际项目中，我们往往需要在一致性、可用性和分区容错性之间做出权衡。你能举例说明在项目中如何权衡这些因素吗？"

廖志伟："当然可以。比如在分布式系统中，为了保证高可用性，我们可能会采用主从复制的方式，但这可能会导致数据一致性问题。在这种情况下，我们可以通过读写分离来提高系统的吞吐量，同时通过缓存来减轻数据库的压力。但这样做可能会牺牲一定的数据一致性，我们需要根据具体业务场景来权衡。"

第五轮：缓存策略的选择

面试官："你提到缓存可以减轻数据库的压力，那么在选择缓存策略时，有哪些因素需要考虑？"

廖志伟："选择缓存策略时，需要考虑多个因素。首先，考虑数据的读写频率。对于读多写少的场景，使用缓存可以显著提高系统的响应速度。其次，考虑数据的实时性要求。如果数据需要实时更新，那么需要选择支持缓存更新的策略。另外，还要考虑缓存的存储容量和失效策略，以及与数据库的同步机制等。"

第六轮：分布式事务处理

面试官："在分布式系统中，处理事务是一个难题。你通常如何处理分布式事务？"

廖志伟："处理分布式事务，我通常会选择两种方案：TCC模式（Try-Confirm-Cancel）和SAGA模式。TCC模式通过在业务操作中引入补偿操作，确保即使在部分操作失败的情况下，也能通过补偿操作恢复到事务开始前的状态。SAGA模式则是将事务分解为一系列的本地事务，每个本地事务完成后再执行下一个事务，从而保证整体事务的原子性。"

第七轮：系统容灾与恢复

面试官："在系统设计中，容灾与恢复是非常重要的。你能否分享一下你在设计系统时如何考虑容灾和恢复？"

廖志伟："在设计系统时，我会从以下几个方面考虑容灾和恢复：首先，确保系统的关键组件如数据库、缓存等都有备份。其次，实现数据的异步复制，确保在主节点故障时，可以从备份节点快速切换。另外，设计故障切换机制，如通过VIP漂移、负载均衡等方式，确保在故障发生时，系统仍然可用。最后，定期进行灾难恢复演练，确保在真正发生故障时，能够快速恢复系统。"

第八轮：微服务架构的设计

面试官："随着微服务架构的流行，你如何看待微服务架构的设计？"

廖志伟："微服务架构是一种将大型系统拆分为多个小型、独立服务的方法，这样可以提高系统的可扩展性和可维护性。在设计微服务架构时，需要考虑服务拆分、服务通信、数据一致性、服务治理等多个方面。关键是要确保各个服务之间能够独立部署、独立扩展，同时保持数据的一致性和服务的可靠性。"

第九轮：云原生技术的应用

面试官："云原生技术近年来越来越受欢迎，你如何看待云原生技术在企业中的应用？"

廖志伟："云原生技术可以帮助企业快速构建、部署和扩展应用程序，提高系统的可扩展性和可维护性。在云原生架构中，容器化和微服务是核心要素。通过容器化，可以将应用程序打包成一个标准化的单元，便于部署和迁移。微服务则使得应用程序更加模块化，便于管理和扩展。云原生技术可以帮助企业更好地适应快速变化的市场需求，提高业务竞争力。"

第十轮：持续集成与持续部署

面试官："持续集成和持续部署是DevOps的重要组成部分，你如何理解并实践持续集成和持续部署？"

廖志伟："持续集成和持续部署是DevOps的核心理念，旨在通过自动化和协作，提高软件开发的效率和质量。在持续集成方面，我会通过自动化构建、测试和部署流程，确保代码质量。在持续部署方面，我会将自动化部署与监控相结合，确保应用程序能够快速、安全地交付到生产环境。通过实践持续集成和持续部署，可以减少人工干预，提高开发效率，降低风险。"

通过以上十轮的面试，面试官和廖志伟共同探讨了分布式系统设计、微服务架构、云原生技术、DevOps等多个方面的知识点，展现了廖志伟在技术领域的深度和广度。

优快云