互联网大厂java求职者面试

我是廖志伟

于 2025-06-06 06:46:46 发布

阅读量688

点赞数 22

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

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

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

版权

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亿次调用的订单系统。那我们假设一下，如果大促期间瞬时下单量突然飙升到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模拟数据不一致场景。"

第四轮：数据一致性保障

面试官："在分布式系统中，数据一致性是一个重要的话题。你提到TCC模式，能否详细解释一下它的原理和适用场景？"

廖志伟："TCC模式，即Try、Confirm、Cancel模式，是一种两阶段提交的变体。在Try阶段，会尝试执行业务逻辑，如果成功，则进入Confirm阶段，正式提交事务；如果失败，则进入Cancel阶段，回滚事务。它适用于业务操作可以拆分成多个步骤的场景，比如支付流程。"

面试官："那么，在实际应用中，如何避免TCC模式带来的死锁问题？"

廖志伟："为了避免死锁，我们可以采用超时机制，即在每个阶段设置超时时间。如果超时，则系统会自动回滚事务，避免死锁的发生。此外，还可以通过数据库锁机制，确保操作的原子性。"

第五轮：系统容错能力

面试官："你提到分布式系统需要具备容错能力。能否举例说明在订单系统中，如何实现故障转移和恢复？"

廖志伟："在订单系统中，我们可以通过以下方式实现故障转移和恢复：首先，使用服务注册与发现机制，比如Eureka或Consul，实现服务的动态注册和发现。其次，使用负载均衡器，如Nginx或Spring Cloud Gateway，实现请求的自动路由。最后，通过熔断降级机制，如Hystrix或Sentinel，在服务不可用时提供备选方案。"

第六轮：分布式事务管理

面试官："分布式事务管理是一个复杂的问题。你提到TCC模式，还有其他方法可以实现分布式事务吗？"

廖志伟："除了TCC模式，还有Choreography模式、SAGA模式等。Choreography模式通过消息队列实现事务协调，而SAGA模式则通过多个本地事务实现分布式事务。具体选择哪种模式，需要根据业务场景和系统架构进行权衡。"

第七轮：系统性能优化

面试官："在订单系统中，如何进行性能优化？"

廖志伟："性能优化可以从多个方面入手。首先，优化数据库查询，比如使用索引、避免全表扫描等。其次，优化服务层，比如使用缓存、异步处理等。此外，还可以通过负载均衡、限流降级等手段，提高系统的整体性能。"

第八轮：系统安全性保障

面试官："在订单系统中，如何保障系统的安全性？"

廖志伟："系统安全性可以从多个方面进行保障。首先，使用HTTPS协议，确保数据传输的安全性。其次，采用权限控制，限制用户对系统的访问。此外，还可以通过日志审计、入侵检测等手段，及时发现并处理安全问题。"

第九轮：系统监控与运维

面试官："在订单系统中，如何进行监控与运维？"

廖志伟："监控与运维可以通过以下方式实现：首先，使用APM工具，如Prometheus和Grafana，对系统性能进行实时监控。其次，通过日志收集和分析，及时发现并解决问题。此外，还可以使用自动化运维工具，如Ansible和Jenkins，提高运维效率。"