费曼学习法
微服务设计与治理
如何设计一个弹性的微服务架构？
核心在于面向失败设计。需要实现服务的熔断、降级、限流和自适应恢复。熔断器（如Hystrix、Sentinel）在失败达到阈值时快速失败；降级在系统压力大时提供有损服务；限流（令牌桶、漏桶算法）控制流量洪峰。此外，服务应无状态化，便于水平扩展；配置应外部化，便于动态调整。
微服务下，如何进行分布式事务管理？
强一致性方案成本高，通常采用最终一致性。核心模式有：1.SAGA模式：将大事务拆分为多个本地事务，每个事务发布事件触发下一个，失败则触发补偿事务反向回滚。2.基于消息的最终一致性：利用可靠消息队列（如RocketMQ事务消息）确保本地事务与消息发送的原子性，消费者保证幂等消费。3.TCC模式：Try（预留资源）、Confirm（确认）、Cancel（取消），由业务代码实现，复杂度高。
服务网格（Service Mesh，如Istio）解决了什么问题？
它将服务间通信的复杂性（如服务发现、负载均衡、熔断、遥测、安全）从应用代码中剥离，下沉到基础设施层，由每个服务伴生的Sidecar代理（如Envoy）统一处理。这使得业务开发者更专注业务逻辑，同时为运维提供了统一的控制面来管理网络策略。
如何有效地进行微服务链路追踪？
通过全局唯一的Trace ID串联一次请求在所有微服务间的路径。在请求入口生成Trace ID，并通过上下文（如HTTP头）在服务间传递。每个服务内部产生Span记录时间点和标签，最终上报到链路追踪系统（如Zipkin、SkyWalking）进行聚合和可视化，帮助定位性能瓶颈和故障点。
API网关除了路由，还有哪些核心功能？
身份认证与授权（集成OAuth2.0/JWT）、API聚合（将多个后端接口合并返回）、协议转换（如gRPC转HTTP）、请求/响应改写、缓存、访问日志和审计。它是内部微服务的防火墙和统一策略执行点。
分布式系统核心问题
分布式系统中，如何实现一个可靠的分布式锁？
常用方案有：1.基于Redis：使用SET key value NX PX timeout命令，保证设置键值和超时的原子性。需解决锁续期（看门狗）和可重入问题。2.基于ZooKeeper：创建临时有序节点，最小节点获锁。利用临时节点的特性，客户端断开则锁自动释放，但需处理“羊群效应”。3.基于etcd：通过租约（Lease）实现。选择需权衡CP（ZooKeeper/etcd）与AP（Redis）特性。
如何理解分布式系统的数据一致性模型？
从强到弱：强一致性：任何时刻读取都是最新数据（如ZooKeeper）。顺序一致性：所有进程看到的操作顺序一致。因果一致性：有因果关系的操作顺序保证。最终一致性：经过一段时间的同步，所有副本最终一致（如DNS、AP型数据库）。互联网系统通常追求最终一致性以换取高可用。
什么是分布式系统的“脑裂”问题？如何应对？
脑裂指集群中节点间网络断开，形成多个小集群，每个都认为自己是主并提供服务，导致数据混乱。解决方案：1.法定票数（Quorum）：必须获得大多数节点同意才能成为主。2.冗余心跳线：避免单网络故障误判。3.Fencing（栅栏）：旧主被隔离后，通过STONITH（射击其他节点）等方式强制使其下线。
在消息队列中，如何保证消息的顺序性？
全局顺序：性能代价大，通常不必要。可将所有消息放入单个分区（如Kafka Partition），由单个消费者处理。
局部（分区）顺序：将需要保证顺序的相关消息（如同一个订单ID、同一个用户ID）通过特定的Key路由到同一个分区。该分区内消息有序，由同一个消费者顺序处理。
如何设计一个高效的分布式ID生成器（发号器）？
主流方案是雪花算法（Snowflake）：64位ID = 时间戳(41位) + 机器ID(10位) + 序列号(12位)。优点是趋势递增、生成快、无需中心化协调。挑战在于机器ID的分配和管理，可借助ZooKeeper或配置中心。其他方案包括：数据库号段模式（每次取一个号段，如[1,1000]，用完再取，性能好）、UUID（无序，影响数据库索引性能）。
性能优化与架构设计
如何进行系统的全链路压测？
数据准备：构造符合生产数据分布的压测数据，并做好数据隔离（影子表、压测标记）。
流量构造：模拟真实用户行为，逐步施压（如阶梯式增压），监控系统拐点。
监控与定位：全链路监控（应用、中间件、OS、网络），关注QPS、响应时间、错误率、资源（CPU、内存、IO）饱和度。定位瓶颈点（如慢SQL、GC频繁、某服务超时）。
优化与验证：针对瓶颈优化后，需重复压实验证效果。
什么是CQRS架构模式？适用于什么场景？
命令查询职责分离。核心思想是将写模型（命令端，处理新增、修改，强调一致性）和读模型（查询端，处理查询，强调性能）分离，甚至使用不同的数据存储。适用于读写负载差异极大的场景，如电商后台（写少但复杂，读多且要求高并发）。常与事件溯源结合，通过事件流重建读模型。
如何理解和应用“缓存预热”？
在系统启动或低峰期，提前将热点数据加载到缓存中，避免高峰时大量请求穿透缓存直接击穿数据库。策略包括：1. 系统启动时全量加载关键数据。2. 定时任务周期性刷新。3. 通过分析历史访问日志，预测并加载潜在热点数据。
数据库读写分离后，如何解决主从延迟带来的数据不一致问题？
这是最终一致性模型下的典型问题。解决方案包括：1.写后强制读主：在关键业务场景（如支付成功后跳转），写操作后的第一次读请求直接走主库。2.二次查询：从库读不到时，回源到主库再查一次。3.关键业务提示：如“数据同步中，请稍后查看”。4. 监控从库延迟，设置阈值告警。
后端接口设计如何兼顾安全与性能？
安全方面：防重放（请求加随机数/时间戳验签）、防篡改（参数签名）、防信息泄露（脱敏）、防越权（校验资源所属）。性能方面：防超时（设置合理超时与重试）、防重复（接口幂等）、防雪崩（熔断降级限流）、防穿透（缓存空值/布隆过滤器）。此外，通过API版本化（如URL路径或请求头）管理迭代，保证兼容性。
Java生态与开发实践
什么是响应式编程（如Reactor、WebFlux）？它解决了什么问题？
一种基于数据流和变化传播的声明式编程范式。核心是通过异步非阻塞的方式处理请求，用少量固定线程处理高并发IO操作，避免线程阻塞和上下文切换，提高系统吞吐量和资源利用率。适用于高并发、低延迟的IO密集型场景（如网关、消息推送），但调试复杂度增加。
记录类（Record，Java 14+正式）是什么？解决了什么问题？
一种用于透明地承载不可变数据的简洁语法。编译器会自动生成final字段、全参构造器、equals、hashCode、toString和访问器方法。它旨在替代那些仅用于存储数据的、样板代码繁多的POJO类（如DTO、值对象），使代码更简洁、意图更明确。
虚拟线程（Virtual Threads，Java 19+预览，21+正式）与平台线程有何不同？
平台线程是操作系统线程的包装，重量级，数量有限。虚拟线程是JVM管理的轻量级线程，它与平台线程是M:N调度关系。当虚拟线程执行阻塞操作（如IO）时，会自动从平台线程上卸载，从而释放该平台线程去运行其他虚拟线程。这使得可以“廉价”地创建数百万个虚拟线程，用同步的代码风格获得异步的性能，旨在简化高并发应用开发。
在持续集成/持续部署（CI/CD）流程中，Java项目需要注意哪些环节？
代码质量门禁：集成前通过静态代码分析（SonarQube）、单元测试覆盖率、代码规范检查。
构建与打包：使用一致的构建工具（Maven/Gradle），管理好依赖版本，构建可重复的制品（如JAR、Docker镜像）。
制品管理：将构建产物存入制品库（如Nexus、Jfrog Artifactory）。
自动化测试：包括集成测试、API契约测试等，可在独立的测试环境中进行。
部署与发布：采用蓝绿部署、金丝雀发布等策略，实现平滑上线和快速回滚。
如何理解“云原生”Java应用开发？
核心是让应用生于云，长于云。关键实践包括：1.容器化：使用Docker打包应用及其所有依赖。2.微服务架构：将应用拆分为松散耦合的服务。3.动态管理：通过Kubernetes等进行编排和调度。4.DevOps文化：开发与运维协同。5.声明式API与不可变基础设施。对Java而言，意味着应用启动要快（支持GraalVM Native Image）、内存占用要小、对云环境（配置、服务发现）有天然感知。Spring Boot是云原生Java的重要基石。