Java高频面试题：03

接口幂等性怎么设计仅靠前端生成 token 后端 Redis 先查后删的接口幂等方案在高频场景下会导致业务失败且用户无法重试的严重问题。常见方案缺陷模拟网游点卡抢购场景请求 A 删除 token 后因数据库异常业务失败用户重试的请求 B 因 token 不存在被判定重复提交导致无法下单。优化方案将 Redis 中的 token 改为带 status 的 hash 结构初始 unused用 Lua 脚本保证原子操作判断状态为 unused 则改为 processing 执行业务完成后改为 done重复请求时 processing 状态提示等待done 状态返回结果。兜底方案Redis 失效时通过数据库唯一索引如用户 ID 请求 ID实现幂等插入成功执行业务主键冲突则拦截重复请求。视频建议面试时按缺陷、优化、兜底三层逻辑回答以体现处理生产环境问题的经验。LIMIT 100000000 10和LIMIT 10哪个快视频讲解了 MySQL 分页的性能差异及深度分页的优化方案。分页性能对比视频明确 LIMIT 10 比 LIMIT 100000000 10 更快。因为 MySQL 采用分层架构server 层负责 SQL 解析优化存储引擎负责数据读写执行 LIMIT 100000000 10 时存储引擎需先读取 1 亿条数据并丢弃再返回后续 10 条会浪费大量硬盘、CPU 资源属于深度分页问题。游标式分页优化记住上一页最后一条数据的 id下次查询通过 WHERE idlast_id LIMIT 10 直接取数轻快高效适合下拉加载连续翻页但不支持跳页。子查询优化借助二级索引仅查询索引列和主键获取目标 id再通过主键索引查询全量数据无需全表扫描回表数据量小速度快。搜索引擎优化可使用 Elasticsearch 处理但需注意 Elasticsearch 的 fromsize 也存在深度分页问题需改用 scroll 或 search_after 方式。深度分页的核心问题是大偏移量导致数据库需跳过大量数据需根据业务场景选择对应优化方案。你配了熔断器以为稳了视频通过后端面试场景讲解熔断器的响应时间盲区及微服务防雪崩的三层防御方案。面试场景还原面试官询问有三年经验的后端开发者微服务防血崩方案开发者答用 Hystrix 或 Sentinel 配置失败率触发的熔断器面试官再设场景订单服务调用响应变慢的库存服务因请求未触发失败率熔断阈值订单服务线程池被占满最终崩溃开发者无法给出应对方案。指出核心盲区视频提出熔断器存在响应时间盲区慢响应未触发失败率时会比请求失败更隐蔽地拖垮上游服务。三层防御方案第一层设多维度熔断指标含失败率熔断、慢调用比例熔断、并发数限流第二层采用线程池隔离为每个下游服务分配独立线程池避免慢请求影响其他服务第三层配置熔断后的降级与恢复策略含返回默认值、半开状态试探、实时监控告警。该内容考察开发者从配置工具到设计弹性系统的工程思维。调用第三方接口需要注意哪些问题调用第三方接口需从多维度做好防御性编程以保障系统稳定。超时与重试需设置合理超时时间避免线程被长时间占用实现重试机制注意接口幂等性采用指数退避算法避免加重第三方服务压力。熔断降级使用 Hystrix、Sentinel 等组件第三方接口持续失败或超时自动熔断快速失败避免请求堆积熔断后需有降级方案如返回默认值、用缓存数据等保障核心业务。限流流量控制针对第三方接口调用频率限制用令牌桶或漏桶算法在客户端做限流避免触发对方限流策略被封禁。异常日志处理捕获网络、超时、业务等所有异常记录含请求参数、响应结果、耗时、异常信息的详细日志敏感信息需脱敏。版本兼容处理关注第三方接口版本变更通知代码中做好版本隔离用适配器模式处理版本差异对返回字段做空值判断。安全防护措施API Key、Secret 等敏感信息不硬编码存于配置中心或密钥管理系统用 HTTPS 加密传输对请求参数签名验证防篡改。监控告警设置监控第三方接口调用成功率、响应时间、错误率等指标设置告警阈值指标异常时及时通知处理。掌握这些要点可构建健壮可靠的第三方服务集成系统架构。你用了seata以为分布式事务稳了面试官通过分布式事务场景题考察四年后端开发者对 Seata 及分布式事务的深层理解。Seata AT 模式局限Seata AT 模式通过代理数据源在业务 SQL 执行前后记录 UNDO LOG二阶段提交删日志、回滚时依日志反向补偿若回滚时数据被其他事务修改Seata 无法自动覆盖只能抛出异常需人工介入该模式适合并发冲突概率低的业务不适合秒杀库存等高并发热点场景。TCC 模式补位方案TCC 模式由业务方实现 Try-Confirm-Cancel 三个接口Try 阶段预留资源Confirm 阶段执行Cancel 阶段补偿灵活性更高但开发成本大适合跨行转账等核心强一致性链路且 Confirm 和 Cancel 接口需实现幂等设计。最终一致性兜底可采用本地消息表将业务操作与消息写入放同一本地事务定时扫描推送消息也可通过对账系统每日跑批比对跨系统数据还可与产品沟通接受积分延迟到账等短暂不一致的业务妥协。这道题核心考察开发者从 “用框架” 到 “懂原理、能兜底” 的工程思维。10g日志内存内存只有2ghashmap直接oom视频讲解了 10G 日志文件在仅 2G 内存时找出访问次数最多的前 10 个 IP 的三层处理方案。哈希分流拆分对每个 IP 计算哈希值并对机器数取模将 10G 大文件拆分至对应小文件确保同一 IP 进入同一小文件若小文件仍过大可再次拆分或分发多台机器并行处理将单文件大小控制在内存可承载范围。局部堆排取 Top10将单个小文件读入内存用 HashMap 统计每个 IP 的出现次数维护大小为 10 的小顶堆遍历 HashMap 条目若当前 IP 次数大于堆顶则替换并调整堆无需全量排序即可得到该文件的 Top10。多路归并得全局 Top10收集所有小文件的局部 Top10汇总后再次通过堆排序得到全局访问次数最多的前 10 个 IP若数据量仍大可先取每个小文件的 Top100再合并取 Top10。该方案核心是运用分治思想解决内存不足时的海量数据处理问题。说一下Spring Boot的自动原理视频以工厂搭建场景拆解 Spring Boot 启动核心逻辑适配 Java 面试需求。加载基础环境项目启动入口为启动类的 main 方法调用 SpringApplication.run 后先读取项目的 Application.yml、application.properties 配置文件及系统环境变量获取 server.port、spring.application.name 等基础配置信息。创建 Spring 容器Spring 容器负责管理控制器、服务、数据仓库等所有 Bean 对象开发者可直接从容器获取对象无需手动实例化。自动配置机制Spring Boot 扫描 starter 依赖按需加载对应自动配置类如引入 web starter 则加载 WebMvc、内置 Tomcat 的配置仅当容器无自定义数据源时默认加载 Hikari 数据源可省去 90% 繁琐配置。启动内置服务器自动配置类初始化内置 Tomcat监听配置端口并部署项目容器启动后发布应用就绪事件项目即可通过配置端口访问。Spring Boot 启动核心为加载基础环境、创建容器加自动配置、启动内置服务器三步。MySQL索引有哪些分类Java 面试中仅罗列 MySQL 索引常见类型易不被面试官认可。数据结构维度含 B 树索引默认擅长范围查询、排序聚合、哈希索引等值查询快不支持范围查询、倒排索引用于全文搜索、R 树索引用于多维空间数据查询4 种。InnoDB 实现维度分为聚簇索引即主键索引叶子节点存完整数据行、非聚簇索引叶子节点存索引列和主键值需回表取全行数据。索引性质维度含普通索引仅提升查询速度、主键索引唯一非空一个表仅一个、唯一索引值不重复可含多个 NULL、联合索引多列组合需注意列顺序、全文索引针对长文本关键词搜索、空间索引用于空间数据区域距离查询。按三个维度结构化作答能体现分类思路与底层原理提升面试表现。分布式事务有了解吗跟我讲下不同的事务模式的特性视频讲解了 Seata 框架四种分布式事务模式的特性及适用场景。XA 模式基于两阶段提交协议第一阶段事务协调者询问参与者能否提交第二阶段根据反馈执行提交或回滚优点是一致性强缺点是事务过程锁定资源、并发能力低适合金融转账这类对一致性要求高、并发要求低的场景。TCC 模式属于补偿型模式分为 Try预留资源、Confirm扣减资源、Cancel释放资源三个阶段性能较高为最终一致性适合电商扣减库存这类高并发、可接受短暂不一致的场景。Seata 模式将长事务拆分为多个带补偿操作的本地事务子事务失败时调用补偿回滚吞吐量高但异步补偿无法保证硬性执行适合业务流程长、对执行要求不苛刻的场景如预定业务。AT 模式是 Seata 框架的自动补偿方案通过记录日志实现失败自动回滚对业务代码无侵入、使用简单适合快速接入分布式事务、对一致性要求适中的场景。这些分布式事务模式的本质是在数据一致性与性能之间做权衡订单流水号一般根据什么来生成视频讲解了订单流水号分布式 ID 的一种的核心生成需求与四种常见生成方案。核心生成需求订单流水号需满足全局唯一性、含业务信息的可读性、高生成性能、趋势递增、防止篡改避免暴露业务规模五个核心要求。数据库自增方案分库分表时需用独立表自增 ID缺点是易暴露业务量性能受限于数据库。UUID 方案工作中一般不使用原因是无序、可读性差、存储传输效率低。Redis 原子自增方案用 INCR 命令生成 ID性能远高于数据库但易暴露业务量可添加日期时间戳优化需保证 Redis 高可用。雪花算法方案当前主流选择标准雪花算法生成 64 位 long 类型 ID由符号位、时间戳、机器 ID、序列号组成性能高、可灵活调整位数分配但需解决时间回拨、机器 ID 唯一性问题可参考美团 Leaf 方案的号段模式、雪花模式优化。其中不推荐UUID因为无序而redis原子自增和数据库自增容易暴露业务量