Spring Boot gRPC Kafka Redis互联网医疗预约平台 Java 面试实战场景互联网大厂 Java 求职者面试业务是“互联网医疗预约挂号 智能分诊 实时消息通知平台”。人物面试官严肃、燕双非搞笑的水货程序员第一轮系统架构与核心链路面试官我们先从整体讲起。一个互联网医疗预约平台用户从小程序发起挂号请求后后端链路大概怎么设计燕双非嗯……前面先过网关然后 Spring Boot 接请求查 Redis 看有没有缓存有就直接返回没有就查数据库最后写日志基本就这样。面试官你说的是结果但还缺少关键链路。比如库存、幂等、异步通知、医生排班变更怎么处理燕双非这个……可以用 Kafka 发消息订单创建后异步通知短信和公众号。幂等的话可能加个唯一索引库存的话Redis 先扣一下数据库再落一下。至于排班变更应该也是消息通知吧。面试官方向是对的。那你再说说为什么这里会选择 Spring Boot Kafka Redis 的组合而不是全都同步做完燕双非同步的话用户等得久挂号高峰期容易卡。Redis 可以抗热点Kafka 能削峰填谷Spring Boot 开发快、生态全。嗯我感觉这套组合比较“互联网味儿”。面试官可以至少你抓住了高并发和解耦两个关键词。面试官如果医生临时停诊系统要实时通知已预约用户你会怎么做燕双非停诊后先更新数据库再发 Kafka 消息消费者去发短信、站内信和 WebSocket 推送。前端在线的话就实时弹窗不在线就下次登录看到。面试官很好通知链路基本清楚了。第二轮数据一致性与性能优化面试官挂号下单时怎么避免重复提交比如用户连点两次或者网络重试。燕双非可以前端按钮置灰后端再用 token 做一次性校验。也可以数据库加唯一约束比如一个用户同一时间段只能有一条有效预约。面试官不错。那如果是秒杀式的热门专家号Redis 预扣库存后数据库落库失败怎么办燕双非这就……补偿吧。数据库失败就把 Redis 库存加回去或者发一个回滚消息。要不然就用事务嗯事务应该可以把 Redis 和数据库一起回滚。面试官这里要注意Redis 和数据库不是同一个本地事务不能指望单体事务直接回滚。你说补偿是对的但要设计成最终一致性。继续。面试官再说说缓存策略。医生号源列表、科室列表、用户最近预约记录这三类数据你会怎么缓存燕双非科室列表很稳定适合长缓存号源列表变化快适合短缓存或者主动失效最近预约记录是用户维度数据可以放 Rediskey 带用户 id。高并发下还可以用本地缓存 Caffeine 做二级缓存。面试官回答得不错说明你知道不同数据的时效性差异。面试官如果缓存击穿、穿透、雪崩同时发生你怎么处理燕双非穿透可以布隆过滤器击穿可以互斥锁或者逻辑过期雪崩就给 key 加随机过期时间再配合限流和降级。嗯反正不能全靠“加机器”。面试官这个总结比较完整。面试官最后一个医疗场景对审计要求高如何保证关键操作可追踪燕双非需要统一日志链路记录 traceId、userId、appointmentId结合 Logback/SLF4J 输出结构化日志再配合 Micrometer 指标和链路追踪工具出了问题能查到是谁、什么时候、做了什么。面试官很好已经开始有工程化意识了。第三轮安全、接口与云原生治理面试官医疗系统里身份认证很重要。你会怎么设计登录和授权燕双非登录可以用 JWT移动端拿 token 调接口权限控制可以放 Spring Security 里按角色区分患者、医生、管理员。面试官那 JWT 失效、续期、踢下线怎么做燕双非这个……可以在 Redis 里存一个 token 黑名单或者存 refresh token。要踢下线就把 refresh token 删掉access token 等它过期。大概这样吧。面试官可以至少知道要把状态放到可控存储里。面试官如果你要给医院系统提供内部服务调用为什么还会考虑 gRPC 而不是纯 REST燕双非因为医院内部很多服务是强类型、高频调用比如病历查询、药品库存同步。gRPC 基于 Protobuf性能好接口约束强适合服务间通信对外给前端还是 REST/OpenAPI 更方便。面试官这个区分很好。面试官那服务之间超时、重试、熔断你怎么处理燕双非用 Resilience4j。比如调用库存服务时超时就快速失败短暂故障可以重试但要限制次数连续失败就熔断避免把整个链路拖死。面试官很好说明你知道稳定性治理。面试官假如系统要上 Kubernetes你会关注哪些运行时指标燕双非CPU、内存、线程池、GC、请求延迟、Kafka 堆积、Redis 命中率还有接口错误率。用 Prometheus 和 Grafana 看板监控Micrometer 把应用指标打出来。面试官不错能把应用层和基础设施层联动起来看。面试官今天先到这里你回去等通知吧。所有面试题详细解析1. 医疗预约平台的整体链路设计典型流程是前端提交预约请求 → 网关鉴权与限流 → Spring Boot 服务完成参数校验 → Redis 读取热点号源信息 → 数据库校验最终可用库存 → 成功后写入预约记录 → 发送 Kafka 消息通知短信、站内信、WebSocket 实时推送。核心目标是高可用、低延迟、可扩展、可追踪。2. 为什么要用异步消息挂号成功后短信、公众号、IM、审计日志等操作都不应该阻塞主流程。Kafka 可以把“下单成功”事件广播出去不同消费者独立处理降低耦合并提升吞吐量。3. 幂等与重复提交防重复提交通常是前后端共同治理前端按钮防抖/置灰后端使用一次性 token、幂等键、唯一索引、状态机校验。若用户重复请求服务端应返回同一结果而不是重复创建记录。4. 热点号源的库存一致性Redis 预扣库存适合高并发场景但要接受最终一致性。数据库落库失败时通过补偿消息或定时对账修正库存。不要把 Redis 和 MySQL 误当作同一个事务边界。5. 缓存策略与三大问题穿透请求根本不存在的数据常用布隆过滤器、空值缓存、参数校验。击穿热点 key 失效瞬间被大量请求打穿常用互斥锁、逻辑过期、热点永不过期。雪崩大量 key 同时过期常用随机过期时间、多级缓存、降级与限流。6. 审计与可追踪医疗业务通常有强监管要求关键操作必须留痕。建议统一日志格式记录 traceId、userId、bizId、操作前后状态并接入链路追踪和指标系统便于定位问题和满足审计。7. JWT 与 Spring Security 的结合JWT 适合无状态认证前端携带 token 调用接口Spring Security 负责认证过滤、权限表达式、角色控制和方法级鉴权。若需要踢下线或主动失效通常结合 Redis 维护黑名单、会话版本号或 refresh token。8. 为什么服务间通信考虑 gRPC在医院内部系统中服务之间往往要求高性能和强契约。gRPC 采用 Protobuf序列化快、体积小、接口定义明确适合内部调用对外开放给第三方或前端时REST/OpenAPI 更通用。9. Resilience4j 的作用它用于服务治理包括超时、重试、熔断、限流、隔离等。医疗场景下核心诉求不是“每次都成功”而是“局部故障不影响整体可用性”。例如库存服务超时后可返回兜底结果避免挂号链路被拖垮。10. 监控体系如何搭建Micrometer 负责应用指标采集Prometheus 负责拉取和存储时序数据Grafana 用于可视化。重点关注 QPS、RT、错误率、GC、线程池、Kafka lag、Redis 命中率等指标。11. 业务场景串起来的思维方式真正的面试不是背概念而是要把“预约”“通知”“库存”“安全”“监控”串成完整系统。你每回答一个技术点都要能说明它在业务链路里的位置、解决了什么问题、有什么边界和代价。感谢阅读希望这篇文章能帮助你在 Java 面试中把技术点和业务场景真正串起来也希望能对你的准备有所启发。
