第 11 篇 · 中间件与工程化

这道题考察对"业务流程如何被建模、持久化与驱动执行"这一核心问题的理解。重点不在 API 调用，而在回答：BPMN 2.0 为何要成为标准？流程引擎如何用"状态机 + 令牌(Token)"驱动流程流转？流程定义、部署、实例、任务四者的关系与持久化模型如何设计？为什么工作流引擎必须依赖数据库而非纯内存？

起源：硬编码流程 → 状态机表。早期审批/订单流程用 if-else 加状态字段硬编码，流程变更需改代码发版，难以应对频繁的流程调整与多分支并行。

jBPM（2004，JBoss）：第一代主流工作流引擎，早期基于 jPDL（自有流程定义语言，XML 格式），后支持 BPMN 2.0。与 JBoss 应用服务器深度绑定，社区活跃度后期下降。

Activiti（2010，Alfresco）：由 jBPM 核心开发者 Tom Baeyens 离开 JBoss 后创建，全面拥抱 BPMN 2.0 标准，轻量、易嵌入 Spring，成为 Java 工作流事实标准。5.x 时代统治市场。

Flowable（2016，Activiti 分叉）：Activiti 核心团队因理念分歧从 Activiti 6 分叉出 Flowable，修复历史债务、增强 BPMN/DMN/CMMN 三引擎合一，社区活跃，迁移成本低（API 几乎兼容 Activiti）。

Camunda（2013，Activiti 商业分叉）：同样源自 Activiti，走开源核心 + 商业企业版路线，强调流程监控分析（Operate/Optimize），云原生 Camunda 8 基于 Zeebe 引擎（事件流 + Raft 日志复制，告别数据库轮询），面向高并发云原生场景。

演进驱动力：① 标准化——从私有 jPDL 到 OMG 组织的 BPMN 2.0 标准，实现流程定义跨引擎互通；② 解耦——流程定义与代码解耦，业务流程变更无需发版；③ 云原生——从数据库轮询到事件流日志（Zeebe），突破数据库瓶颈支撑高并发；④ 三引擎合一——BPMN（流程）+ DMN（决策表）+ CMMN（案例）覆盖更复杂的业务编排。

BPMN 2.0 核心元素：

• 事件(Event)：开始事件(圆圈细线)、中间事件(双线圆圈)、结束事件(粗线圆圈)；可带定时/消息/信号/错误等触发器。
• 活动(Activity)：用户任务(人参与)、服务任务(自动调系统)、脚本任务、业务规则任务(调规则引擎)、调用活动(子流程)。
• 网关(Gateway)：排他网关(XOR，条件分支)、并行网关(AND，并发汇合)、包容网关(OR，条件并发)、事件网关。
• 顺序流(Sequence Flow)：连接元素的带箭头线，可带条件表达式。

核心概念关系：

执行原理：Token(令牌) 漫游模型。流程引擎本质是一个持久化的状态机，每条执行路径用一个 Execution（执行实例）表示，可理解为在 BPMN 图上移动的"令牌"：

1. 启动：调用 runtimeService.startProcessInstanceByKey(...)，从开始事件创建根 Execution，落库 ACT_RU_EXECUTION。
2. 流转：沿顺序流前进，遇到网关则求值条件表达式(用 JUEL/SpEL)决定分支；遇到并行网关则分裂出多个子 Execution 并发前进。
3. 等待：遇到用户任务则创建 Task 落库 ACT_RU_TASK，流程在此挂起（无锁等待，靠数据库持久化状态），引擎线程退出。
4. 推动：用户 complete 任务 → 引擎从库中加载 Execution → 令牌继续前进 → 到达下一节点。这种"前进-落库-挂起-加载-继续"的断点续跑模式，正是引擎依赖数据库的根本原因。
5. 结束：令牌到达结束事件，流程实例完成，运行态数据迁入历史表。

为何依赖数据库：流程是长生命周期状态机（审批可能跨天/跨人/跨服务重启），必须将当前令牌位置、流程变量持久化，才能在任意时刻加载恢复并继续。这正是 Activiti 历史表(RU 运行态 + HI 历史 + RE 仓库 + GE 通用)设计的根本动机。Zeebe 用事件流日志(Raft 复制)替代数据库轮询，本质仍是持久化，只是存储与并发模型换了。

Activiti 整合 Spring Boot 的典型用法：

// 1. 部署 BPMN 流程定义(也可自动部署 classpath:processes/*.bpmn20.xml)
Deployment dep = repositoryService.createDeployment()
    .addClasspathResource("processes/leave-approve.bpmn20.xml")
    .deploy();

// 2. 启动流程实例,带业务主键与流程变量
Map<String, Object> vars = new HashMap<>();
vars.put("starter", "zhangsan");
vars.put("amount", 15000);
ProcessInstance pi = runtimeService.startProcessInstanceByKey(
    "leaveApprove", "LEAVE-2026-0001", vars);

// 3. 查询当前用户的待办任务
List<Task> tasks = taskService.createTaskQuery()
    .taskAssignee("lisi")
    .processDefinitionKey("leaveApprove")
    .orderByTaskCreateTime().desc()
    .list();

// 4. 完成任务,推动流程前进(可带审批结果变量)
Map<String, Object> approve = new HashMap<>();
approve.put("approved", true);
approve.put("comment", "同意");
taskService.complete(task.getId(), approve);

// 5. 服务任务用 Java Delegate 自动执行(无需人工)
public class ArchiveService implements JavaDelegate {
    @Override
    public void execute(DelegateExecution exec) {
        String bizKey = (String) exec.getProcessInstanceBusinessKey();
        archiveService.archive(bizKey);  // 调用业务归档
    }
}

选型建议：传统企业内嵌审批（请假/报销/合同）选 Flowable 7（社区活跃、API 兼容 Activiti、三引擎合一）；云原生高并发流程编排选 Camunda 8/Zeebe（事件流、无数据库轮询）；轻量级无状态编排可考虑直接用状态机框架（Spring Statemachine / Squirrel）而非重型 BPMN 引擎。

追问 1：流程引擎如何保证流程不"卡死"？长时间挂起的任务如何处理？

① 定时任务(Job)——BPMN 定时边界事件/中间事件会产生定时 Job，引擎 JobExecutor 周期扫描 ACT_RU_JOB 触发；② 超时提醒——任务加边界定时事件，超时自动触发催办或自动流转；③ 挂起与激活——流程定义或实例可整体挂起（暂停流转），处理完异常再激活；④ 补偿与撤销——BPMN 补偿事件可回滚已完成的副作用；⑤ 死信队列——失败的 Job 进入死信，需人工干预。Camunda 8 用 Job Worker 拉取模式与重试机制处理。

追问 2：Activiti 与 Flowable 的核心区别是什么？如何迁移？

Flowable 是 Activiti 6 的分叉，API/表结构高度兼容。区别：① Flowable 修复了大量历史 bug，DMN/CMMN 实现更完整；② Flowable 支持 Spring Boot 2/3 starter 更积极；③ Flowable 7 重构了引擎模块化。迁移：表结构基本一致，可直接换依赖；注意自定义查询 SQL 与历史 API 的细微差异，建议充分回归测试。

考察"配置驱动 vs 代码驱动"的工程取舍。核心回答：如何把审批人、审批角色、跳转条件、超时策略、表单字段等节点属性从 BPMN XML 与代码中抽离，做成可运营配置的"流程定义元数据"，做到不改流程定义、不发版即可调整节点行为。难点在于配置粒度与灵活性的平衡、批量配置的存储模型、以及运行时如何注入。

阶段 1：硬编码节点属性。审批人写死在 BPMN XML 的 assignee 表达式，跳转条件写死在网关表达式。任何调整都要改 XML 重新部署流程定义，运营成本高。

阶段 2：流程变量驱动。审批人改为 ${assigneeMap.get(nodeId)}，从流程变量读取，但变量需在启动时传入或在监听器中计算，仍较死板。

阶段 3：任务监听器 + 配置表。用 TaskListener 在节点 create 时查配置表动态设置审批人、表单、跳转条件。配置存数据库，运营后台可改。这是当前主流方案。

阶段 4：低代码流程设计器 + 元数据驱动。前端可视化拖拽生成流程，节点属性全部元数据化（JSON Schema），引擎运行时解析元数据驱动，配合 DMN 决策表做条件路由。Camunda/Flowable 的 Modeler + DMN 即此路线。

阶段 5：AI 辅助流程编排。趋势：用 LLM 根据自然语言描述生成 BPMN 草图与节点配置，人工校验后发布，降低流程建模门槛。

配置化核心模型：流程节点配置表。把每个节点的可变属性抽象成一张配置表，按 (processKey, nodeKey, tenantId) 维度存储，运行时通过监听器/执行监听器注入：

批量配置的关键设计：① 配置缓存——节点配置查询频繁，用本地缓存(Caffeine)+版本号失效，避免每次查库；② 租户隔离——同一流程不同租户节点配置不同，配置表加 tenant_id；③ 配置版本化——配置变更版本化，运行中实例按启动时快照执行，避免配置变更影响在途流程；④ 动态表达式求值——条件与审批人表达式用 EL 引擎(Activiti 用 JUEL，也可换 SpEL/QLExpress)在运行时求值。

基于 TaskListener 的节点配置化实现：

// 节点配置实体(对应 wf_node_config 表)
@Data
@TableName("wf_node_config")
public class WfNodeConfig {
    private Long id;
    private String processKey;     // 流程定义 key
    private String nodeKey;       // 节点 ID(BPMN 中的 task id)
    private String tenantId;      // 租户隔离
    private String assigneeType;  // USER/ROLE/DEPT/EXPR/SCRIPT
    private String assigneeValue; // 审批人值或表达式
    private String skipCondition; // 跳过条件(如金额<1000 自动通过)
    private Integer timeoutHours;
    private String formJson;      // 表单 JSON Schema
    private Integer configVersion;
}

// 统一节点配置监听器:在任务 create 时注入审批人/跳过/超时
@Component("nodeConfigListener")
public class NodeConfigListener implements TaskListener {
    @Autowired private WfNodeConfigService configService;
    @Autowired private AssigneeResolver resolver;

    @Override
    public void notify(DelegateTask task) {
        String processKey = task.getProcessDefinitionId().split(":")[0];
        String tenant = task.getTenantId();
        // 1. 查节点配置(带缓存)
        WfNodeConfig cfg = configService.getConfig(processKey, task.getTaskDefinitionKey(), tenant);
        if (cfg == null) return;
        // 2. 跳过条件判断:满足则自动 complete
        if (resolver.evalSkip(cfg.getSkipCondition(), task.getVariables())) {
            task.setVariable("_autoSkip_", true);
            return;
        }
        // 3. 解析并设置审批人(USER/ROLE/EXPR 多类型)
        List<String> assignees = resolver.resolve(cfg, task);
        if (assignees.size() == 1) {
            task.setAssignee(assignees.get(0));
        } else {
            assignees.forEach(u -> task.addCandidateUser(u));
        }
        // 4. 超时策略:挂边界定时(通过定时任务扫描超时任务)
        if (cfg.getTimeoutHours() != null) {
            task.setVariable("_timeout_", cfg.getTimeoutHours());
        }
    }
}

// BPMN 中所有用户任务统一挂监听器(设计器导出时自动加)
// <userTask id="managerApprove" activiti:taskListener="delegateExpression=${nodeConfigListener}"/>

批量运营能力：① 运营后台提供"流程节点配置"批量编辑页，按流程维度一次性配置所有节点；② 配置变更走审批流，灰度生效（新启动实例用新配置，在途实例按旧快照）；③ 配置导出导入支持跨环境同步；④ 关键节点配置变更触发告警通知流程负责人。

追问 1：配置变更后，在途流程实例用旧配置还是新配置？

原则：在途实例按启动时配置快照执行，保证一致性。实现：启动时把节点配置版本号存入流程变量，监听器按该版本号查历史配置。如需强制升级在途实例，提供"流程迁移"功能（Camunda/Flowable 原生支持 Process Instance Migration），将实例迁移到新流程定义+新配置，但需充分测试兼容性。

追问 2：如何实现"会签"（多人全部同意才通过）与"或签"（任一同意即通过）的配置化？

用 BPMN 多实例任务(Multi-Instance)：① 并行会签——parallel multi-instance，completionCondition 设 ${nrOfCompletedInstances == nrOfInstances}（全部完成）；② 或签——completionCondition 设 ${nrOfCompletedInstances/nrOfInstances >= 0.0001} 或用 nrOfActiveInstances == 0 配合一票通过逻辑。会签人数从配置读取动态设置 collection 变量，监听器在 create 时注入人员列表。

考察"业务规则如何与代码解耦并高效执行"的架构能力。核心回答：规则引擎的本质是把"条件-动作"规则从硬编码抽离成可配置数据，运行时按数据匹配执行。需深入 QLExpress 的 AST 编译执行与 Drools 的 Rete 网络算法原理，以及从硬编码→脚本→规则引擎→决策引擎的演进逻辑与选型决策矩阵。

阶段 1：硬编码 if-else。规则写死在代码里，"满 100 减 20""VIP 打 8 折"用 if-else 实现。规则变更需发版，规则爆炸后代码不可维护，是"规则地狱"的起源。

阶段 2：脚本引擎(2000s)。用 Groovy/JavaScript(JSR-223)/Aviator 把规则抽成脚本，存数据库动态加载。灵活性提升，但脚本无规则匹配优化，规则多了仍全量执行，且脚本能力过强易出安全问题。

阶段 3：规则引擎(2010s)。QLExpress（阿里，2008，轻量嵌入式）、Drools（Red Hat，基于 Rete 算法，重）、EasyRules（轻量声明式）。提供规则 DSL、匹配算法、议程(Agenda)管理，规则与执行分离。

阶段 4：决策引擎/决策表(DMN)。DMN(Decision Model and Notation)标准——决策表(Decision Table)可视化配置输入-输出映射，业务人员可直接维护。Drools DMN、Flowable DMN、Camunda DMN 均支持。比规则引擎更易理解，适合结构化决策。

阶段 5：智能决策(趋势)。规则引擎 + ML 模型 + LLM 混合决策：简单规则用规则引擎（可解释、可审计），复杂非线性用 ML 模型，模糊判断用 LLM。规则引擎负责"硬性约束"，模型负责"柔性预测"。

QLExpress 执行原理：AST 编译 + 解释执行。QLExpress 是阿里开源的轻量脚本引擎，语法接近 Java：

1. 词法分析：源码 → Token 流（关键字/标识符/运算符）。
2. 语法分析：Token 流 → AST(抽象语法树)，每个表达式节点是树的一个节点。
3. 编译优化：AST 可编译为指令序列或直接解释执行；支持预编译缓存 AST，避免重复解析。
4. 运行时求值：递归遍历 AST 求值，支持上下文变量注入、自定义函数、沙箱安全控制（禁用反射/类加载）。

QLExpress 是线性执行，适合"一段脚本求值"，规则多了需自己组织循环匹配，无 Rete 的共享优化。

Drools 执行原理：Rete 网络(核心)。Rete(Latin "net")算法是 Drools 的高效规则匹配引擎，针对"大量规则 + 大量事实(Fact)"场景优化：

• Alpha 网络：对每个 Fact 做单条件过滤（如 age > 18），形成 Alpha 节点，相同条件的规则共享节点，避免重复判断。
• Beta 网络：对多条件 join（如 age>18 AND vip=true），用 Beta 节点做跨字段连接，共享中间结果。
• Terminal 节点：匹配成功的规则进入 Agenda(议程)。
• 议程冲突解决：多条规则同时匹配，按 salience(优先级)/LIFO 等策略排序执行。
• 增量更新：Fact 插入/修改/删除只重新评估受影响节点，O(1) 增量而非全量重算，这是 Rete 对朴素循环匹配的关键优化。

选型对比：

QLExpress 营销规则配置化实战：

// 1. 规则实体(存数据库,运营可配)
@Data
public class MarketingRule {
    private Long id;
    private String name;
    private String condition;   // QLExpress 表达式: amount>1000 && userLevel==3
    private String action;      // 动作脚本: return amount*0.1
    private Integer priority;   // 优先级
}

// 2. 规则执行引擎(带 AST 缓存 + 沙箱)
@Component
public class QlExpressEngine {
    private final Map<String, ExpressNode> astCache = new ConcurrentHashMap<>();
    private final ExpressRunner runner;

    public QlExpressEngine() throws Exception {
        runner = new ExpressRunner();
        // 沙箱:禁用反射/类加载,防注入
        runner.addFunctionOfServiceMethod("sendCoupon", couponService, ...);
    }

    public Object execute(String expr, Map<String, Object> ctx) throws Exception {
        ExpressNode ast = astCache.computeIfAbsent(expr,
            k -> runner.parseInstructionSet(k));  // AST 缓存
        DefaultContext<String, Object> context = new DefaultContext<>();
        context.putAll(ctx);
        return runner.execute(ast, context, null, false, true);
    }
}

// 3. 按优先级匹配规则并执行(营销场景)
public BigDecimal calcDiscount(Order order, User user) {
    List<MarketingRule> rules = ruleService.listEnabled().stream()
        .sorted(Comparator.comparing(MarketingRule::getPriority).reversed())
        .collect(Collectors.toList());
    Map<String, Object> ctx = new HashMap<>();
    ctx.put("amount", order.getAmount().doubleValue());
    ctx.put("userLevel", user.getLevel());
    for (MarketingRule rule : rules) {
        if ((Boolean) engine.execute(rule.getCondition(), ctx)) {
            return new BigDecimal(engine.execute(rule.getAction(), ctx).toString());
        }
    }
    return BigDecimal.ZERO;
}

选型决策：① 规则<100 条且需业务运营自配 → QLExpress + 配置表 + 沙箱（轻量、上手快）；② 规则上万且 Fact 频繁增量变更 → Drools Rete（增量匹配高效）；③ 纯公式/条件表达式 → Aviator（极致性能）；④ 结构化决策(输入输出映射) → DMN 决策表（业务可维护）。

追问 1：规则引擎的规则热更新如何实现？如何保证不停机生效？

① QLExpress/Aviator：规则存数据库，AST 缓存按规则版本号失效，运营改规则后版本号变更，下次执行重新解析缓存；② Drools：用 KieScanner 监控 Maven 仓库的 kjar 更新，自动 reload 新版 KieBase，或用 KieSession 动态 insert/update 规则；③ 灰度发布：新规则先灰度部分流量验证，再全量；④ 回滚：规则版本化，异常时秒级回退旧版本。注意热更新时在途求值不受影响（用旧 AST 完成当前执行）。

追问 2：规则引擎与状态机如何协作？

分工：状态机管"流程编排"（节点流转、状态转换），规则引擎管"节点内的决策"（如审批人决策、跳转条件、折扣计算）。例如订单状态机驱动"待支付→已支付→已发货"，每一步的"是否免运费""送多少积分"用规则引擎计算。两者解耦：流程变更改状态机，策略变更改规则，互不影响。

考察对"第三方授权访问"机制的深度理解。核心回答：OAuth 本质是委托授权协议（让用户授权第三方应用访问其在另一服务上的资源，而不交出密码），而非认证协议。需厘清 OAuth 2.0 四种模式如何收敛为 2.1 三种模式、为何废弃隐式与密码模式、授权码+PKCE 为何成为推荐方案、令牌刷新与吊销机制。

OAuth 1.0（2007）：首个开放授权协议，用 HMAC-SHA1 签名每个请求，安全性高但签名计算复杂、强制 HTTPS、难以扩展，且仅支持一种流程。

OAuth 2.0（2012，RFC 6749）：彻底重写，引入多种授权模式（授权码/隐式/密码/客户端凭证），用 Bearer Token 替代签名（依赖 HTTPS 保护传输），大幅简化但安全性争议大：隐式模式令牌暴露在前端、密码模式暴露用户密码给客户端。

OAuth 2.1（草案，2020+）：收敛而非新增，把 2.0 的最佳实践固化成标准——废弃隐式模式(Implicit)与密码模式(Password)，强制所有客户端用授权码+PKCE，统一安全基线。本质是"2.0 + BCP(Best Current Practice) 的合并整理"。

为何废弃隐式与密码模式：① 隐式模式——令牌直接通过 URL fragment 返回前端，暴露在浏览器历史/Referer/日志，且无法发 refresh token，被授权码+PKCE 完全取代；② 密码模式——第三方应用拿到用户账号密码，违背 OAuth"不交出密码"初衷，且密码泄露风险高，应改用授权码模式（用户在授权服务器页面登录，密码不经过客户端）。

OAuth 2.1 实际保留的三种模式（原四种收敛）：

授权码 + PKCE 流程（核心）：PKCE(Proof Key for Code Exchange) 解决"授权码被恶意应用拦截"问题。恶意应用在移动端可注册相同 URL Scheme 拦截回调，PKCE 让拦截到 code 也换不到 token：

PKCE 防拦截原理：客户端发起时只给授权服务器 code_challenge（verifier 的哈希），换 token 时才给 code_verifier。恶意应用即使拦截到 code，因为没有 verifier，授权服务器用 challenge 校验 verifier 失败，拒绝换 token。等价于"预共享密钥 + 哈希证明"。

安全考量要点：① 强制 HTTPS——Bearer Token 明文传输，必须 TLS 保护；② state 参数防 CSRF——客户端生成随机 state，授权服务器原样返回，客户端校验一致才接受，防止跨站请求伪造；③ 令牌最小权限与短有效期——access_token 有效期短（分钟~小时），refresh_token 长但可吊销；④ 令牌存储——Web 用 HttpOnly+Secure Cookie，SPA 用内存(BFF 模式更佳)，移动端用系统级安全存储；⑤ 客户端密钥保护——公开客户端(SPA/App)无法安全存 secret，正是 PKCE 存在的意义。

Spring Security OAuth2 授权服务器配置（Spring Authorization Server）：

@Configuration
@EnableWebSecurity
public class AuthServerConfig {
    @Bean
    public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http) throws Exception {
        OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);
        http.getConfigurer(OAuth2AuthorizationServerConfigurer.class)
            .oidc(OidcConfigurer::disable);  // 不启用 OIDC 简化
        return http.build();
    }

    @Bean
    public RegisteredClientRepository registeredClientRepository() {
        RegisteredClient client = RegisteredClient.withId("spa-client")
            .clientId("spa-client")
            // 公开客户端(SPA): 不设 secret, 强制 PKCE
            .clientAuthenticationMethod(ClientAuthenticationMethod.NONE)
            .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
            .redirectUri("https://app.example.com/callback")
            // 强制 PKCE: 客户端必须带 code_challenge
            .requireProofKey(true)
            .scope("read").scope("write")
            .clientSettings(ClientSettings.builder().requireAuthorizationConsent(true).build())
            .tokenSettings(TokenSettings.builder()
                .accessTokenTimeToLive(Duration.ofMinutes(30)
                .refreshTokenTimeToLive(Duration.ofDays(7))
                .reuseRefreshTokens(false)  // refresh 一次失效,防重放
                .build())
            .build();
        return new InMemoryRegisteredClientRepository(client);
    }
}

// 资源服务器: 校验 access_token
@Bean
public SecurityFilterChain resourceServerFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/public/**").permitAll()
        .anyRequest().authenticated())
        .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);
    return http.build();
}

BFF(Backend For Frontend) 模式：SPA 不直接持有 token，而是用一层后端(BFF)完成授权码交换，token 存 BFF 的 HttpOnly Cookie，前端用 Cookie 访问 BFF，BFF 带 token 调资源服务。避免 token 暴露在前端 JS，是 OAuth 2.1 SPA 的推荐架构。

追问 1：OAuth 2.0 与 OpenID Connect(OIDC) 的关系？

OAuth 2.0 是授权协议（Authorization，给第三方访问资源的权限），不是认证协议（Authentication，证明用户是谁）。OIDC 是构建在 OAuth 2.0 之上的认证层：在授权流程中额外返回 ID Token(JWT)，包含用户身份声明(sub/email/name)，客户端验签 ID Token 即完成认证。OIDC = OAuth 2.0 + ID Token + 标准化用户信息端点(UserInfo Endpoint)。要做"登录"用 OIDC，要做"授权访问 API"用 OAuth 2.0。

追问 2：refresh_token 轮换与检测机制如何防重放？

① refresh_token 轮换——每次用 refresh_token 换新 access_token 时，同时发新的 refresh_token 并使旧的失效（reuseRefreshTokens=false）；② 重放检测——若已失效的 refresh_token 被再次使用，说明可能被盗，授权服务器应立即吊销该客户端该用户的所有 token 链（RFC 7009 token revocation）；③ sender-constrained token——用 DPoP 或 mTLS 把 token 与客户端密钥绑定，盗走也用不了。

考察对"无状态令牌"机制的深度理解与安全权衡。核心回答：JWT 本质是把声明(Claim)编码成自包含的 JSON 串并用签名保证不可篡改，使服务端无需查库即可验证。需厘清 Header/Payload/Signature 三段结构、JWS vs JWE、JWT 续期与吊销的难点、为何要双 Token 机制，以及从 Session 到 JWT 的认证演进动机。

阶段 1：Session + Cookie（有状态）。服务端存 Session（内存/Redis），Cookie 带 SessionID。优点：可强制下线、可统计在线数。缺点：① 扩展性差——分布式需 Session 共享（Spring Session+Redis）；② 移动端不友好——Cookie 跨域问题；③ 服务端有状态，违背 REST 无状态理念。

阶段 2：JWT（无状态）。服务端签发 JWT，客户端存储并携带（Header/Body），服务端验签即可，无需存 Session。优点：无状态、易扩展、跨域友好、移动端友好。缺点：① 无法主动吊销——签发后有效期内一直有效；② 续期难——不能像 Session 自动续期；③ Payload 不加密（默认 Base64）。

阶段 3：双 Token（Access + Refresh）。access_token 短期（如 30 分钟）用于 API 访问，refresh_token 长期（如 7 天）用于换新 access_token。兼顾安全（access 短期，泄露损失小）与体验（refresh 静默续期，免频繁登录）。是当前主流。

阶段 4：Opaque Token + 令牌内省（趋势）。JWT 无状态导致吊销难，部分场景回归"不透明令牌 + 内省端点(Introspection)"，token 是随机串，服务端调授权服务器内省校验，可即时吊销。Gateway 做内省缓存兼顾性能。或用 JWT + 黑名单/版本号折中。

JWT 三段结构：Header.Payload.Signature，均 Base64URL 编码，用点号连接。

// Header: 算法与类型
{
  "alg": "HS256",   // 签名算法(HMAC-SHA256 / RS256 / ES256)
  "typ": "JWT"
}

// Payload: 声明(Claims) —— 注意默认不加密,只 Base64
{
  "sub": "10086",          // subject 用户ID
  "name": "张三",
  "roles": ["admin"],
  "iss": "auth-server",    // issuer 签发方
  "aud": "order-service",  // audience 受众(防跨服务滥用)
  "exp": 1735689600,       // expiration 过期时间
  "iat": 1735687800,       // issued at 签发时间
  "jti": "uuid-xxx"         // JWT ID 唯一标识(用于吊销)
}

// Signature: 用 Header.alg 对 "Base64(Header).Base64(Payload)" 签名
HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

JWS vs JWE：① JWS(JWT Signature)——只签名不加密，保证完整性（防篡改）但不保密（Payload 可解码），是日常说的 JWT；② JWE(JWT Encryption)——对 Payload 加密，保证机密性，第三方无法读取内容，适合敏感声明。需保密用 JWE，只需防篡改用 JWS。

验签流程：① 解析三段；② 用密钥对 Header+Payload 重新计算签名，与 Signature 比对；③ 校验 exp(未过期)、iss(签发方)、aud(受众)等声明。任一失败则拒绝。密钥管理：HS256 对称密钥（签发与验证同一密钥，需安全共享）；RS256/ES256 非对称（私钥签发、公钥验证，公钥可公开，适合微服务多验签方）。

双 Token 续期与吊销：

• 续期：access_token 过期 → 客户端用 refresh_token 调 /refresh → 服务端校验 refresh_token 有效性 → 签发新 access_token（可选同时轮换 refresh_token）。
• 吊销难点：JWT 无状态，签发后无法主动失效。方案：① 黑名单——把要吊销的 jti 存 Redis，验签时查黑名单（牺牲无状态）；② 短有效期——access_token 设很短（15-30 分钟），吊销靠等过期；③ 版本号——用户 token 加 version 字段，改密码/登出时 version+1，旧 token 版本不符即失效；④ refresh_token 吊销——refresh_token 存库，登出删除，阻断续期链。

双 Token 认证实现（Spring Security + jjwt）：

@Component
public class JwtTokenService {
    @Value("${jwt.secret}") private String secret;
    @Value("${jwt.access-ttl:1800}") private long accessTtl;   // 30 分钟
    @Value("${jwt.refresh-ttl:604800}") private long refreshTtl; // 7 天

    // 1. 登录成功签发双 Token
    public TokenPair issue(LoginUser user) {
        String accessJti = UUID.randomUUID().toString();
        String access = Jwts.builder()
            .subject(user.getId().toString())
            .claim("name", user.getName())
            .claim("roles", user.getRoles())
            .claim("ver", user.getTokenVersion())  // 版本号用于吊销
            .id(accessJti)
            .issuer("auth-server")
            .audience().add("app").and()
            .issuedAt(new Date())
            .expiration(new Date(System.currentTimeMillis() + accessTtl * 1000))
            .signWith(Keys.hmacShaKeyFor(secret.getBytes()), Jwts.SIG.HS256)
            .compact();
        // refresh_token 存 Redis 便于吊销
        String refreshJti = UUID.randomUUID().toString();
        String refresh = Jwts.builder().subject(user.getId().toString())
            .id(refreshJti).claim("type", "refresh")
            .expiration(new Date(System.currentTimeMillis() + refreshTtl * 1000))
            .signWith(Keys.hmacShaKeyFor(secret.getBytes()), Jwts.SIG.HS256).compact();
        redisTemplate.opsForValue().set("refresh:"+refreshJti, user.getId(), refreshTtl, TimeUnit.SECONDS);
        return new TokenPair(access, refresh);
    }

    // 2. 解析与校验(含版本号校验,支持吊销)
    public Claims parse(String token) {
        Claims c = Jwts.parser().verifyWith(Keys.hmacShaKeyFor(secret.getBytes()))
            .requireAudience("app").build().parseSignedClaims(token).getPayload();
        Long ver = c.get("ver", Long.class);
        Long curVer = userService.getTokenVersion(Long.parseLong(c.getSubject()));
        if (!Objects.equals(ver, curVer)) throw new TokenRevokedException("token 已吊销");
        return c;
    }

    // 3. 登出: 删除 refresh + 版本号+1(吊销所有 access)
    public void logout(Long userId, String refreshJti) {
        redisTemplate.delete("refresh:"+refreshJti);
        userService.incrTokenVersion(userId);  // access 立即失效
    }
}

追问 1：JWT 与 Session 的本质区别？何时该用哪个？

本质：Session 是服务端有状态(状态在服务端)，JWT 是客户端有状态(状态在 token 里)。Session 优势在可控（随时下线、在线统计），劣势在扩展（需共享存储）；JWT 优势在无状态易扩展，劣势在不可控（难即时吊销）。选型：① 单体/需强制下线/在线管理 → Session；② 微服务/移动端/跨域/无状态 API → JWT；③ 高安全要求（金融）→ Opaque Token + 内省，可即时吊销。也可混合：网关用 Opaque，内部服务用 JWT。

追问 2：JWT 的 alg=none 漏洞是怎么回事？

历史漏洞：JWT Header 可指定 alg:none 表示不签名，若服务端未强制校验算法，攻击者把 alg 改成 none 并篡改 Payload 即可伪造任意身份。防御：验签时强制指定允许的算法白名单（如只允许 HS256/RS256），拒绝 none 与不接受 Header 里 alg 字段指定的非白名单算法。现代 JWT 库默认已防御，但仍需显式配置算法。

考察"从代码提交到生产部署的自动化流水线如何标准化、可复制、安全可控"的工程架构能力。核心回答：CI(持续集成)与 CD(持续交付/部署)的边界、流水线的阶段划分与质量门禁、多环境部署策略、以及从 Jenkins 到 GitLab CI 到 GitOps(ArgoCD) 的演进逻辑与声明式 IaC 思想。

阶段 1：手工构建部署。开发本地打包上传服务器，手动停服务替换 jar 启动。易错、慢、不可重复、无审计。

阶段 2：Jenkins 脚本式（2011+）。Jenkins 用 Shell/Freestyle 脚本编排构建部署，配合插件生态。Jenkinsfile(Pipeline as Code) 把流水线存代码库，可版本化。痛点：① 命令式——脚本描述"怎么做"，部署逻辑分散难复用；② Push 模式——Jenkins 主动 push 部署到目标环境，权限与状态分散在 Jenkins；③ 插件地狱，升级维护成本高。

阶段 3：GitLab CI/GitHub Actions（2015+）。CI 配置(.gitlab-ci.yml/.github/workflows)与代码同库，Runner 执行 job。比 Jenkins 轻、与 Git 深度集成、YAML 声明式。但仍多为 Push 部署，K8s 部署需在脚本里写 kubectl。

阶段 4：GitOps(ArgoCD/Flux，2018+)。把期望状态(部署清单)存 Git，集群内的 Controller(ArgoCD) 持续比对 Git 期望状态与集群实际状态，发现偏差自动 Pull 同步。Git 成为唯一可信源(Single Source of Truth)，部署即 commit，回滚即 revert。

GitOps 核心原则：① 声明式——系统期望状态用声明式描述(K8s YAML/Helm/Kustomize)；② 版本化与不可变——期望状态存 Git，任何变更留痕可审计可回滚；③ 自动 Pull——集群内 Agent 主动拉取 Git 状态应用到集群，而非外部 Push；④ 持续协调——Controller 持续 reconcile 实际状态向期望状态收敛。这使部署更安全(审计)、更可靠(状态一致)、更易回滚(revert commit)。

CI/CD 标准流水线阶段：

GitOps 工作流(ArgoCD)：

关键区分：CI 负责构建产物（镜像、制品）并更新配置仓库中的镜像 tag；CD(ArgoCD) 负责把配置仓库的期望状态同步到集群。两者解耦：CI 不直接碰生产集群（无生产凭据），生产部署权在 ArgoCD（集群内、有审计），安全边界清晰。

GitLab CI 流水线 + ArgoCD GitOps 标准实践：

# .gitlab-ci.yml —— 业务代码仓库
stages:
  - lint
  - test
  - build
  - sync-manifest   # 更新配置仓库,触发 ArgoCD 同步

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

lint:
  stage: lint
  script:
    - mvn checkstyle:check
    - sonar-scanner -Dsonar.qualitygate.wait=true   # 质量门禁

unit-test:
  stage: test
  script:
    - mvn test
    - mvn jacoco:report
  coverage: '/Total.*?([0-9]{1,3})%/'   # 提取覆盖率

build-image:
  stage: build
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE
    - trivy image --exit-code 1 --severity CRITICAL $IMAGE  # 镜像安全扫描

# 关键: 不直接部署,而是更新配置仓库的镜像 tag
sync-manifest:
  stage: sync-manifest
  only:
    - main
  script:
    - git clone https://oauth2:$DEPLOY_TOKEN@gitlab.com/org/deploy-manifests.git
    - cd deploy-manifests
    - sed -i "s|image:.*|image: $IMAGE|" prod/order-service/deployment.yaml
    - git commit -am "chore: bump order-service to $CI_COMMIT_SHORT_SHA"
    - git push origin main   # ArgoCD 监听此仓库自动同步

# 配置仓库 deploy-manifests/prod/order-service/deployment.yaml (ArgoCD 监听)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  annotations:
    argocd.argoproj.io/sync-options: Prune=true
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:abc1234   # CI 更新此 tag
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "sleep 10"]   # 优雅停机

---
# ArgoCD Application 声明(指定监听哪个仓库同步到哪个集群)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service-prod
spec:
  source:
    repoURL: https://gitlab.com/org/deploy-manifests.git
    path: prod/order-service
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true          # 自动清理多余资源
      selfHeal: true        # 有人手改集群资源会自动纠正回 Git 状态
    strategy:
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 0     # 滚动发布:先增后减,不中断

多环境管理：用 Kustomize overlays（base + dev/test/prod 覆盖）或 Helm values 管理环境差异。环境晋升：dev 自动部署 → test 审批后部署 → prod 审批+灰度部署。回滚：GitLab CI revert 配置 commit，ArgoCD 自动同步回旧版本。

追问 1：GitOps 的 selfHeal 会不会有风险？

selfHeal 会在有人手动 kubectl 改集群资源后自动纠正回 Git 状态，保证一致性。风险：① 紧急手动止血被回滚——运维紧急改副本数扩容，selfHeal 立即改回，需有"暂停同步"机制(ArgoCD pause)；② 配置错误快速传播——Git 错误配置快速同步到所有集群。建议：生产环境 selfHeal 谨慎开启，配合 PR 审批 + ArgoCD 同步窗口 + 健康检查(Sync Wave + Health Check)。

追问 2：如何做 GitOps 下的数据库 schema 变更？

GitOps 管应用部署，数据库变更需单独流水线：① 用 Liquibase/Flyway 管理 schema 版本，变更脚本随代码库版本化；② CI 阶段执行 schema migration（向前兼容，扩展→双写→切读→收缩）；③ 不与 ArgoCD 同步耦合——ArgoCD 只管 K8s 资源，DB 变更在 CI 中独立执行并校验；④ 回滚：DB schema 不回滚（向前兼容设计），应用回滚到能兼容当前 schema 的旧版本。

考察"如何在不侵入业务代码的前提下，对分布式系统全链路进行性能监控与问题定位"的架构设计能力。核心回答：APM 的本质是字节码增强 + 上下文透传 + 采样聚合，需深入 Java Agent + Instrumentation 字节码增强原理、微内核+插件架构设计、Trace/Span 模型，以及从字节码增强到 OpenTelemetry 到 eBPF 的监控技术演进。

阶段 1：日志 + 手动埋点。靠日志打印耗时，手动在代码加时间戳统计。侵入性强、覆盖不全、无跨服务关联。

阶段 2：字节码增强 APM（2012+）。Pinpoint（Naver，2012）、SkyWalking（Apache，2015）、ARMS（阿里）。基于 Java Agent + Instrumentation 在类加载时改写字节码，自动给主流框架(Spring/MyBatis/Redis/RPC)加埋点，业务零侵入。生成 Trace 树可视化调用链。

阶段 3：OpenTelemetry 标准化（2019+）。CNCF 主导，合并 OpenTracing + OpenCensus，统一 Trace/Metrics/Log 三支柱标准与 SDK。厂商中立，可对接任意后端(Jaeger/Prometheus/Tempo)。从"各家私有 SDK"走向"标准 SDK + 多后端"。

阶段 4：eBPF 内核级无侵入（2021+）。eBPF(extended Berkeley Packet Filter) 在 Linux 内核运行沙箱程序，无需 Java Agent、无需改字节码，从内核态捕获网络调用(syscall/socket)自动关联 Trace。代表：Pixie、Cilium Tetragon、Datadog eBPF。优势：语言无关、零应用侵入、内核级精度；限制：需 Linux 4.4+/5.x+ 内核。

演进驱动力：① 降低侵入——从手动埋点到字节码增强到内核 eBPF，侵入性递减；② 标准化——从厂商私有 SDK 到 OpenTelemetry 统一标准，解耦采集与后端；③ 语言无关——eBPF 突破 Java Agent 只能监控 JVM 的限制，覆盖 Go/Rust/Node 等多语言。

Java Agent + Instrumentation 字节码增强原理（APM 核心）：Java Agent 通过 premain（启动时）或 agentmain（运行时 attach）入口，注册 ClassFileTransformer 在类加载时拦截字节码，用 ByteBuddy/ASM 对目标方法前后插入埋点代码（start span/end span/异常记录）。各框架增强逻辑独立插件化（Spring/MyBatis/Dubbo 各一插件），微内核按需加载。Java Agent 启动配置与 OTel 集成示例详见 C11.09。

Trace/Span 模型：一次请求的完整调用链是一棵 Trace 树，每个方法调用是一个 Span（含 traceId/spanId/parentId/operationName/时间/标签/日志）。跨服务透传 traceId 串起多服务 Span。三支柱关联、采样策略与 OTel 标准详见 C11.09。

APM 系统架构（微内核+插件）——五件套全景：

采样策略：全量上报数据量大，需采样：① 头部采样——入口按比例(如 10%)决定是否采样，整条链路全采或不采；② 尾部采样——全链路跑完根据结果(慢/错)决定是否上报，能保证所有异常链路被采，但需暂存全量 Span；③ 自适应采样——流量大时降采样率，流量小时提高。

自研 APM vs 选型开源：

• 自研动机：① 需深度定制埋点逻辑（如业务标签染色）；② 数据安全要求私有化；③ 学习字节码增强技术底座。但维护成本高。
• 开源选型：中小团队选 SkyWalking（Apache 顶级、国产、Java 生态完善、UI 友好）；大规模多语言选 OpenTelemetry + Jaeger/Tempo（标准、厂商中立）；商业选 ARMS/Datadog（开箱即用）。

自研 APM 关键设计点：① 微内核+插件——核心只做字节码增强引擎与上下文管理，各框架增强逻辑独立插件，按需加载，避免臃肿；② 异步上报——埋点数据先入进程内无锁队列(Disruptor)，异步批量上报，不阻塞业务线程；③ 上下文透传——ThreadLocal 存当前 Span，跨线程用 TransmittableThreadLocal，跨服务注入 HTTP Header；④ 采样与降级——Agent 内置采样器，Collector 压力大时动态降采样；⑤ 低开销——字节码增强只拦截必要方法，避免高频方法，实测开销 < 5%。

典型问题定位场景：① 慢接口定位——调用链拓扑看耗时分布在哪个 Span（DB?下游RPC?），逐层下钻；② 错误根因——过滤 error Span，看异常堆栈与 tags；③ 服务拓扑发现——自动生成服务依赖拓扑图，发现非预期依赖；④ 容量规划——按服务 QPS/RT 趋势做容量预估。

追问 1：字节码增强对应用性能的影响如何控制？

① 选择性增强——只增强"有意义"的方法（RPC 调用、DB 访问、HTTP 出口），不增强高频内部方法；② 异步上报——埋点只做内存记录，上报走异步队列，不阻塞业务；③ 无锁设计——上下文用 ThreadLocal 避免竞争，队列用 Disruptor 无锁；④ 采样——不全量上报；⑤ 预热与缓存——字节码改写结果缓存，反射结果缓存。优秀 APM(如 SkyWalking)生产环境开销可控制在 3-5%。

追问 2：eBPF 监控相比 Java Agent 的优势与边界？

优势：① 语言无关——内核态捕获 syscall，Java/Go/Python 通吃；② 零应用侵入——不改字节码、不挂 Agent；③ 内核级精度——能看到网络层细节。边界：① 需较新内核（4.4+/5.x+）；② 无法获取应用层语义——只看到 syscall 不知道是哪个业务方法，需配合 OTel 补充应用层 Trace；③ 权限要求高——需 root/CAP_BPF。趋势：eBPF 做网络层底层 Trace，OTel 做应用层语义 Trace，两者融合。

考察"分布式上下文如何在各种执行边界间无缝传递"的工程能力。核心回答：TraceId 透传的本质是上下文(Context) 在执行边界（线程切换/线程池/异步/跨进程）的接力。需厘清 ThreadLocal/MDC 的单线程局限、线程池下 ThreadLocal 失效原因与 TaskDecorator/TTL 解法、跨服务 HTTP/RPC 透传协议(W3C TraceContext)，以及 Virtual Thread 下的兼容性。

阶段 1：ThreadLocal（单线程内）。同一线程内用 ThreadLocal 存 TraceId，日志从 MDC 取。局限：线程切换即丢失（线程池复用线程，主线程的 ThreadLocal 传不到工作线程）。

阶段 2：手动传递 + InheritableThreadLocal。InheritableThreadLocal 在创建子线程时继承父线程上下文。局限：① 只在 new Thread() 时继承，线程池复用线程不触发（线程早已创建，提交任务时不继承）；② 需手动把 TraceId 塞 Runnable。

阶段 3：TransmittableThreadLocal(阿里 TTL)。解决线程池场景——在提交任务时（而非创建线程时）捕获当前上下文，在任务执行前回放、执行后还原。用 TtlRunnable.get(runnable) 包装或 TtlExecutors.getTtlExecutorService 装饰线程池。是线程池透传主流方案。

阶段 4：Virtual Thread 兼容（Java 21+）。Virtual Thread 是轻量线程，每次阻塞 IO 会 unmount/mount carrier thread，ThreadLocal 会有继承与拷贝开销问题。Scoped Values（JDK 21 引入，JDK 25 JEP 506 正式转正）是 ThreadLocal 的替代，专为虚拟线程设计。OTel SDK 已适配 Virtual Thread，MDC 在虚拟线程下仍可用但需注意开销。

阶段 5：W3C TraceContext 标准。跨服务透传从各家私有 Header(B3/X-B3) 趋向 W3C 标准 traceparent/tracestate Header，保证多厂商互通。

ThreadLocal 为何在线程池失效：ThreadLocal 的数据存在 Thread.threadLocals 字段，每个线程独立。线程池中工作线程是复用的——提交任务时主线程的 ThreadLocal 不会自动拷贝到工作线程（拷贝只在 new Thread() 时由 InheritableThreadLocal 触发）。所以主线程存的 TraceId，工作线程取不到。

TTL 透传原理：TransmittableThreadLocal 重写在提交任务时（TtlRunnable 包装）捕获(capture)当前线程的所有 TTL 值，任务执行前回放(replay)到工作线程，执行后还原(restore)工作线程原值（避免污染下次复用）。本质是"提交时快照 + 执行时注入 + 执行后清理"。

跨服务透传：W3C TraceContext：HTTP 请求加 Header traceparent: 00-{traceId}-{spanId}-{flags}，下游解析并延续 traceId。RPC(Dubbo/gRPC) 用 attachment/metadata 透传。MQ 把 traceId 塞消息属性(Properties)，消费端取出放入当前上下文。

方案 1：MDC + TaskDecorator（Spring 线程池透传）：

// 1. Web 过滤器: 入口生成/解析 traceId 存 MDC
@Component
public class TraceFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp, FilterChain chain) throws Exception {
        // 优先从 W3C traceparent 解析,无则生成
        String traceId = Optional.ofNullable(req.getHeader("traceparent"))
            .map(h -> h.split("-")[1]).orElse(UUID.randomUUID().toString().replace("-", ""));
        MDC.put("traceId", traceId);
        resp.setHeader("X-Trace-Id", traceId);
        try { chain.doFilter(req, resp); }
        finally { MDC.clear(); }
    }
}

// 2. 线程池 TaskDecorator: 提交时拷贝 MDC,执行时回放,完成后清理
@Component
public class MdcTaskDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        Map<String, String> ctx = MDC.getCopyOfContextMap();  // 主线程快照
        return () -> {
            Map<String, String> old = MDC.getCopyOfContextMap();
            try {
                if (ctx != null) MDC.setContextMap(ctx);  // 回放
                runnable.run();
            } finally {
                if (old != null) MDC.setContextMap(old);  // 还原
                else MDC.clear();
            }
        };
    }
}

@Configuration
public class ThreadPoolConfig {
    @Bean("orderExecutor")
    public ThreadPoolTaskExecutor orderExecutor(MdcTaskDecorator decorator) {
        ThreadPoolTaskExecutor exec = new ThreadPoolTaskExecutor();
        exec.setCorePoolSize(8);
        exec.setMaxPoolSize(32);
        exec.setTaskDecorator(decorator);   // 关键: 装饰任务透传 MDC
        exec.initialize();
        return exec;
    }
}

方案 2：TransmittableThreadLocal（更通用，覆盖 CompletableFuture/并行流）：

// 用 TTL 替代 ThreadLocal 存上下文
public class TraceContext {
    public static final TransmittableThreadLocal<String> TRACE_ID = new TransmittableThreadLocal<>();
}

// 线程池用 TtlExecutors 装饰,CompletableFuture/并行流自动透传
@Bean
public ExecutorService traceExecutor() {
    ExecutorService raw = new ThreadPoolExecutor(8, 32, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>());
    return TtlExecutors.getTtlExecutorService(raw);  // 包装后自动透传 TTL
}

// 跨服务 HTTP 透传: RestTemplate 拦截器注入 traceparent
@Component
public class TraceInterceptor implements ClientHttpRequestInterceptor {
    @Override
    public ClientHttpResponse intercept(HttpRequest req, byte[] body, ClientHttpRequestExecution exec) throws IOException {
        String traceId = TraceContext.TRACE_ID.get();
        if (traceId != null) {
            req.getHeaders().set("traceparent", "00-"+traceId+"-"+genSpanId()+"-01");
        }
        return exec.execute(req, body);
    }
}

// MQ 透传: 生产者塞消息属性,消费者取出放上下文
@Component
public class MqTraceProducer {
    public void send(String topic, Object payload) {
        Message msg = MessageBuilder.withPayload(payload)
            .setHeader("traceId", TraceContext.TRACE_ID.get())  // 塞消息属性
            .build();
        kafkaTemplate.send(topic, msg);
    }
}
@KafkaListener(topics = "order")
public void onMessage(ConsumerRecord<String, String> record) {
    String traceId = new String(record.headers().lastHeader("traceId").value());
    TraceContext.TRACE_ID.set(traceId);  // 消费端恢复上下文
    try { handle(record.value()); }
    finally { TraceContext.TRACE_ID.remove(); }
}

追问 1：CompletableFuture 并行编排时 TraceId 如何透传？

CompletableFuture 默认用 ForkJoinPool.commonPool，其线程复用且无 TTL 透传。解法：① 显式传自定义 TTL 线程池——supplyAsync(supplier, ttlExecutor)；② 手动包装——在 supplyAsync 的 lambda 里先回放上下文再执行业务；③ allOf/anyOf 后续 thenApply 仍在异步线程，需确保链上每一步都在 TTL 线程池执行。最稳妥是全程用 TTL 装饰的线程池，不要用默认 commonPool。

追问 2：Virtual Thread 下 ThreadLocal 有什么问题？Scoped Values 如何替代？

Virtual Thread 数量可能极大（百万级），每个虚拟线程都继承 ThreadLocal 会导致内存膨胀与继承开销。JDK 21 预览的 Scoped Values（ScopedValue.where(KEY, val).run(()->...)）是不可变、有界、自动清理的上下文传递机制，专为虚拟线程设计，避免 ThreadLocal 的继承开销与泄漏问题。OTel 已用 Context 基于 ThreadLocal 适配虚拟线程，未来将迁移到 Scoped Values。

考察"可观测性(Observability) 如何标准化落地"的架构能力。核心回答：可观测性区别于监控(Monitoring)——监控只能发现"预设的已知问题"(阈值告警)，可观测性通过 Metrics/Trace/Log 三支柱的关联分析，回答"为什么出问题、还有哪些未知问题"，三支柱必须通过 TraceId 统一关联形成闭环。OpenTelemetry(OTel) 作为统一标准的架构（API+SDK+Collector）终结厂商锁定，落地重心在 OTel Collector 管道工程（pipeline/receiver/processor/exporter、Service Graph Connector、Tail Sampling Processor）与部署模式（Agent/Deployment/Gateway 三级拓扑）。

阶段 1：传统监控/日志为主（2000s）。Nagios/Zabbix 基于阈值告警，ELK 统一日志采集检索，Metrics 靠 Zabbix/Nagios 独立，Trace 几乎没有。三支柱割裂，只能覆盖已知失败模式，排障需跨系统跳转。

阶段 2：Dapper 奠基 + APM 兴起（2010-2012）。Google Dapper 论文奠定分布式追踪理论基础——Span 树 + TraceId 串联跨服务调用链；Pinpoint/SkyWalking/Cat 提供调用链 Trace，Prometheus 统一 Metrics，日志仍 ELK。三支柱各有工具但标准不统一、厂商锁定严重——换 APM 厂商需重写埋点。

阶段 3：OpenTracing + OpenCensus（2016-2019）。OpenTracing（CNCF，Trace 标准 API）与 OpenCensus（Google，Trace+Metrics 标准）两套标准并存，生态碎片化，使用者困惑。

阶段 4：OpenTelemetry 统一（2019+）。CNCF 合并两者成 OpenTelemetry(OTel)，提供厂商中立的 API + SDK + Collector + OTLP 协议，统一 Trace/Metrics/Log 三支柱。一次埋点，可导出到任意后端(Jaeger/Tempo/Prometheus/Loki/ES)，成为 CNCF 仅次于 K8s 的第二大项目。

阶段 5：eBPF 补充 + 生态融合（2021+）。OTel eBPF Profiler 从内核采集无侵入 Profile，补足应用层 Trace 看不到的网络/系统层细节；Spring Boot 3.2+ 内置 Micrometer Tracing(桥接 OTel/Brave)；JDK 21 虚拟线程带来 ThreadLocal 上下文传播新挑战。

可观测性三支柱基础：

• Metrics(指标)——聚合数值，低成本高吞吐，适合告警与趋势分析。Counter(单调递增：请求数/错误数)、Gauge(瞬时值：连接数/队列长度)、Histogram(分布：RT 分位 P99)；Exemplar 在指标数据点中嵌入 TraceId，实现 Metrics→Traces 跳转。
• Traces(追踪)——Span 树形结构，还原请求在分布式系统中的完整路径。TraceId(全局唯一 128bit)/SpanId(64bit)/ParentSpanId 建立父子关系；跨服务透传 traceId 串起多服务 Span。
• Logs(日志)——结构化日志(JSON 格式)，携带 TraceId/SpanId 字段，实现 Logs→Traces 跳转。

OpenTelemetry 架构：API + SDK + Collector：

三层解耦：① API 层——业务代码只依赖 OTel API（接口），不绑定具体实现；② SDK 层——运行时实现，配置采样率、批处理、导出协议，可替换；③ Collector 层——独立部署的管道，核心是 pipeline 管道：receivers（接收）→ processors（处理）→ exporters（导出）。三层解耦使"换后端不改业务代码"成为可能。

OTLP 协议：OTel 自定义的高效协议，gRPC/HTTP 双传输，支持 Trace/Metrics/Log 三种信号统一传输，是 OTel 的原生协议。Collector 间也可用 OTLP 转发，支持级联部署。

Collector 管道深度解析：Receiver / Processor / Exporter 三角色：

• Receivers（接收器）：数据入口。otlp（gRPC 4317/HTTP 4318，接收 SDK 上报）、prometheus（pull 方式抓取指标）、kafka（从 Kafka 消费缓冲数据，抗峰削谷）、filelog（tail 本地日志文件）。同一 Collector 可同时启多个 receiver 接收不同信号。
• Processors（处理器核心能力）：管道的"大脑"。① batch——批量合并减少网络请求（必配，timeout 5s/send_batch_size 1024）；② memory_limiter——软限制内存防 OOM（limit_percentage 80，必配）；③ filter——按属性过滤噪音（如过滤 /actuator/health 健康检查 Span）；④ resource——统一注入/富化 service.name、k8s.pod.name 等资源标签；⑤ tail_sampling——Collector 缓冲完整 Trace，按策略（ERROR 状态/慢调用/概率）决定保留（配置见工程实践）；⑥ servicegraph（Service Graph Connector）——从 Trace Span 聚合生成服务调用拓扑（A→B 调用次数/RT），供 Grafana Tempo 的"服务图"直接展示。
• Exporters（导出器）：数据出口。otlp（发给下一级 Collector 或 Jaeger/Tempo）、prometheusremotewrite（写给 VictoriaMetrics/Prometheus）、kafka（写入 Kafka 做缓冲层）、debug（stdout 打印排障用）。

Collector 三级部署拓扑（生产推荐）：

拓扑分工：① Agent 级（DaemonSet 每节点一个）——只做接收 + 轻量 batch，无 tail_sampling 等重处理器，避免占用业务节点资源，本地就近上报减少跨节点流量；② Gateway 级（独立 Deployment）——做重处理（tail_sampling/servicegraph/跨集群路由），集中式多副本弹性伸缩，与业务节点资源隔离。

Context/Baggage 传播：Context 携带 TraceId/SpanId；Baggage 携带业务自定义 KV(如 userId)；跨服务通过 W3C TraceContext HTTP Header(traceparent)传播；进程内通过 ThreadLocal + MDC(SLF4J) 自动注入日志。跨线程/线程池/虚拟线程下 TraceId 透传完整治理方案（TTL/MDC TaskDecorator/Context.wrap 对比）详见 C11.08。

采样策略（存储成本与完整性的平衡）：高 QPS 链路用 Head Sampling(入口概率采样降开销)，关键链路用 Tail Sampling(全量采集后在 Collector 按错误/慢调用筛选保留)；两者对比详见深度追问 2。

Spring Boot 集成 OpenTelemetry（Java Agent 自动埋点）：

# 启动加 OTel Agent(零代码侵入自动埋点 Spring/MyBatis/Redis/HTTP)
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=order-service \
  -Dotel.exporter.otlp.endpoint=http://otel-collector:4317 \
  -Dotel.traces.sampler=parentbased_traceidratio \
  # 10% 采样
  -Dotel.traces.sampler.arg=0.1 \
  -Dotel.metrics.exporter=otlp \
  -Dotel.logs.exporter=otlp \
  -jar order-service.jar

# OTel Collector 配置 otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  batch: { timeout: 5s, send_batch_size: 1024 }   # 批量减少请求
  memory_limiter: { check_interval: 1s, limit_percentage: 80 }  # 限流防 OOM
  filter:                                          # 过滤健康检查噪音
    traces:
      span:
        - 'attributes["http.target"] == "/actuator/health"'

exporters:
  otlp/jaeger: { endpoint: jaeger:4317, tls: { insecure: true } }  # Trace
  prometheusremotewrite: { endpoint: http://prometheus:9090/api/v1/write }  # Metrics
  otlp/loki: { endpoint: loki:4317 }             # Log

service:
  pipelines:
    traces:  { receivers: [otlp], processors: [memory_limiter, filter, batch], exporters: [otlp/jaeger] }
    metrics: { receivers: [otlp], processors: [memory_limiter, batch], exporters: [prometheusremotewrite] }
    logs:    { receivers: [otlp], processors: [memory_limiter, batch], exporters: [otlp/loki] }

手动埋点补充业务语义（自动埋点覆盖通用框架，业务关键节点需手动加 Span/Attribute）：

@Autowired private Tracer tracer;  // OTel Tracer

public Order createOrder(OrderRequest req) {
    Span span = tracer.spanBuilder("createOrder").startSpan();
    try (Scope scope = span.makeCurrent()) {
        span.setAttribute("order.userId", req.getUserId());  // 业务标签
        span.setAttribute("order.amount", req.getAmount().doubleValue());
        Order order = orderRepo.save(buildOrder(req));
        span.addEvent("order.created", Attributes.of(AttributeKey.stringKey("orderId"), order.getId()));
        return order;
    } catch (Exception e) {
        span.recordException(e);  // 异常记录到 Span
        span.setStatus(StatusCode.ERROR);
        throw e;
    } finally { span.end(); }
}

Micrometer 自定义业务指标 + Exemplar 自动关联 Trace（Spring Boot Actuator + Micrometer 暴露 /actuator/prometheus，OTel SDK 自动将当前 Span 的 TraceId 作为 Exemplar 嵌入指标）：

// Micrometer 自定义业务指标 + Exemplar 自动关联 Trace
@Service
@RequiredArgsConstructor
public class OrderMetrics {
    private final MeterRegistry registry;

    // Counter: 订单创建数(按渠道标签)
    public void recordOrder(String channel, boolean success) {
        registry.counter("order.create.total",
                "channel", channel,
                "result", success ? "success" : "fail")
            .increment();
    }

    // Timer: 订单处理耗时(自动关联 Exemplar -> Trace)
    public void recordProcessTime(String channel, long millis) {
        registry.timer("order.process.duration",
                "channel", channel)
            .record(millis, TimeUnit.MILLISECONDS);
    }
}

Tail Sampling Collector 配置（保留错误与慢调用）：

# otel-collector: Tail Sampling 保留错误与慢调用 Trace
processors:
  tail_sampling:
    decision_wait: 30s        # 缓冲 30s 等待完整 Trace
    policies:
      # 保留所有错误请求的 Trace
      - name: error-status
        type: status_code
        status_code:
          status_codes: [ERROR]
      # 保留慢调用(大于 2s)
      - name: slow-trace
        type: latency
        latency:
          threshold_ms: 2000
      # 10% 采样其余(基线覆盖)
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

平台选型：① 开源自建(Prometheus+Grafana+Tempo/Loki，成本低可控)；② SaaS(Datadog，开箱即用但贵)；③ 云厂商(阿里云 ARMS，深度集成云资源)。

落地建议：① 优先用 Java Agent 自动埋点覆盖通用框架，零侵入；② 关键业务方法手动加 Span + 业务 Attribute，便于按业务维度筛选；③ Collector 独立部署，配置 batch + memory_limiter 防背压；④ 三后端分离部署（Jaeger/Prometheus/Loki），用 Grafana 统一面板关联展示；⑤ 采样率从低开始(10%)，异常链路用尾部采样保证采到；⑥ SLO 告警基于 SLI——定义服务等级指标(可用率/延迟 P99/错误率)，多窗口多燃烧率告警避免抖动误报；⑦ 深度观测可用 eBPF(Cilium/Hubble) 做内核层网络流量零侵入观测。

追问 1：OTel 如何解决厂商锁定？迁移后端成本多大？

OTel 三层解耦是关键：业务代码只依赖 OTel API（接口），SDK 与 Collector 是实现层。换后端只需改 Collector 的 exporter 配置（如 Jaeger→Tempo），业务代码零改动。甚至可同时导出多后端做灰度验证。相比传统 APM 换厂商需重写所有埋点，OTel 把迁移成本从"月级代码改造"降到"分钟级配置变更"。

追问 2：OpenTelemetry 的 Head Sampling vs Tail Sampling 有什么区别？

Head Sampling(头部采样)：在请求入口(Trace 起点)立即按概率决定是否采样，一旦不采样则后续所有 Span 都不生成。优点是开销极小(下游零埋点)；缺点是无法根据"是否出错/是否慢"决策——错误请求可能被提前丢弃。Tail Sampling(尾部采样)：所有 Span 全量采集传到 Collector，Collector 缓冲完整 Trace 后(等待 decision_wait)，根据策略(错误状态/延迟/属性)决定是否保留。优点是能精准保留错误与慢调用；缺点是需要 Collector 缓冲内存、有延迟。生产实践：入口用低比例 Head Sampling 降流量 + Collector Tail Sampling 保留异常 Trace。

追问 3：Metrics 和 Traces 如何关联(Exemplar)？

Prometheus Exemplar 机制：Histogram/Counter 的数据点可附带一个 TraceId 引用。当 Micrometer 记录指标时，OTel SDK 自动将当前 Span 的 TraceId 作为 Exemplar 嵌入。在 Grafana 中点击指标图表上的 Exemplar 点，可直接跳转到 Tempo/Jaeger 查看该请求的完整 Trace——实现从"指标异常(如 P99 飙升)"到"具体请求链路"的下钻分析。这是三支柱联动的关键纽带。

追问 4：Metrics、Trace、Log 数据量差异巨大，如何差异化存储与采样？

① Metrics——数据量小且聚合，通常全量保留，存 Prometheus/VictoriaMetrics（时序库，高效压缩）；② Trace——数据量大，需采样（头部 10% 或尾部只采异常/慢），存 Jaeger/Tempo（Trace 库），用采样率控制量；③ Log——数据量最大，分级采集（ERROR 全采，INFO 采样），存 Loki/ES（日志库），按保留期滚动删除。Collector 对三种信号分别配 pipeline 与采样策略，差异化处理。

追问 5：TraceId 跨线程透传如何治理？

核心问题是 ThreadLocal 在线程池场景失效，治理方案包括 TransmittableThreadLocal(TTL)、Spring TaskDecorator、OTel Context.wrap() 三对比，MDC 注入/清理防串流，以及虚拟线程下的 Scoped Values 演进。完整代码示例与原理拆解见 C11.08。

考察"如何主动注入故障，验证系统在真实异常下的韧性"的架构能力。核心回答：混沌工程的本质是用受控的故障实验提前发现系统脆弱点，而非"搞破坏"。需厘清稳态假设(Steady State Hypothesis)这一核心方法论、故障注入实验设计流程、爆炸半径(Blast Radius)控制、以及从测试到混沌工程的演进与工具选型。

阶段 1：传统测试。单元/集成/性能测试验证"正常路径"与"已知异常路径"，但无法覆盖生产环境的复杂不可预见故障（网络抖动、实例掉线、依赖超时组合）。

阶段 2：故障演练（GameDay）。运维手动制造故障（kill 实例、断网），观察系统反应。有价值但不可重复、覆盖窄。

阶段 3：Netflix Chaos Monkey（2011）。Netflix 在 AWS 随机 kill 生产实例，验证弹性。开创混沌工程(Chaos Engineering) discipline——"在生产环境主动注入故障验证韧性"。后续 Simian Army 一系列猴子（Latency Monkey 注入延迟、Conformity Monkey 检查合规等）。

阶段 4：混沌工程平台化（2018+）。ChaosBlade（阿里，开源，故障场景丰富）、Litmus（CNCF，K8s 原生）、Chaos Mesh（CNCF，K8s 原生，CRD 定义实验）、AWS FIS。从"随机杀实例"演进到可控、可编排、可度量的实验平台。

阶段 5：持续混沌与自适应韧性（趋势）。① 持续混沌——实验自动化纳入 CI/CD，每次发布自动跑混沌实验验证韧性回归；② 自适应弹性——根据混沌实验结果自动调整容量/限流/熔断阈值；③ 多维度故障组合——从单故障注入到多故障组合（网络分区+磁盘满+实例宕），逼近真实灾难场景。

混沌工程核心原则（Netflix 四原则）：① 定义稳态——用可度量指标(QPS/RT/错误率)定义系统"正常"状态；② 假设稳态在故障下保持——提出假设"注入某故障后稳态指标仍正常"；③ 在真实环境注入故障——在生产或类生产环境注入（而非测试环境，因生产最真实）；④ 证明或证伪假设——观察稳态指标是否被破坏，证伪则发现脆弱点，修正后系统更韧性。

稳态假设（Steady State Hypothesis）是灵魂：混沌工程不是"为搞破坏而搞破坏"，而是科学实验——先定义稳态指标，假设故障下稳态保持，注入故障验证假设。有明确假设与度量，才能判断实验"通过"还是"发现脆弱点"。

故障注入维度：

爆炸半径(Blast Radius) 控制：故障实验必须可控，避免把生产搞挂。① 小范围开始——先单个实例/单个可用区；② 自动中止——稳态指标超阈值自动停止实验；③ 灰度扩大——验证小范围无影响再扩大范围；④ 回滚预案——实验前准备快速回滚；⑤ 非高峰期——选低峰时段实验降低影响。

Chaos Mesh（K8s 原生）实验定义：

# Chaos Mesh: 向 order-service 注入网络延迟,验证降级生效
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: order-service-latency
spec:
  action: delay          # 延迟故障
  mode: all              # 目标 Pod 选择
  selector:
    namespaces: [prod]
    labelSelectors: { app: order-service }
  delay:
    latency: "500ms"     # 注入 500ms 延迟
    correlation: "100"
    jitter: "50ms"
  duration: "2m"          # 持续 2 分钟
  scheduler:
    cron: "@every 1h"     # 每小时一次(持续混沌)

---
# Pod 故障: 随机 kill 1 个实例,验证 K8s 自愈
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: random-pod-kill
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces: [prod]
    labelSelectors: { app: order-service }
  duration: "0s"          # 立即 kill
  scheduler:
    cron: "@every 30m"

稳态监控与自动中止（关键安全机制）：

# 稳态假设: 实验期间 order-service 错误率 < 1%, RT < 500ms
# Chaos Mesh 配 statusCheck,超阈值自动中止实验
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata: { name: order-resilience-test }
spec:
  entry: main
  templates:
    - name: main
      templateType: Serial
      children: [inject-fault, check-steady]
    - name: inject-fault
      templateType: NetworkChaos
      networkChaos:
        action: delay
        delay: { latency: "500ms" }
        duration: "3m"
    - name: check-steady
      templateType: StatusCheck
      statusCheck:
        duration: "3m"
        conditions:
          - type: Prometheus
            query: "rate(http_requests_total{status=~\"5..\"}[1m]) / rate(http_requests_total[1m])"
            comparison: { operator: le, value: "0.01" }   # 错误率 < 1%
        failureThreshold: 1    # 1 次不满足即中止
        intervalSeconds: 10

落地路径：① 从非生产开始——先在类生产环境演练，验证实验流程与回滚；② 单服务单故障——从单服务注入单故障（如延迟），观察降级是否生效；③ 逐步扩大——扩大爆炸半径（多实例/多服务）与故障组合；④ 纳入 CI/CD 持续混沌——关键服务每次发布自动跑韧性实验；⑤ 建设韧性档案——记录每次实验的脆弱点与修复，形成系统韧性知识库。

工具选型：K8s 环境首选 Chaos Mesh（CNCF、CRD 声明式、生态好）；非 K8s/物理机用 ChaosBlade（阿里，故障场景丰富、支持 JVM 级）；云上托管用 AWS FIS/阿里云 AHAS；轻量实验用 Gremlin（商业）。

追问 1：混沌工程与测试、SRE 的关系？

混沌工程是测试的延伸——测试验证"已知预期"，混沌工程探索"未知未预期"的复杂故障组合，覆盖测试覆盖不到的生产复杂性。与 SRE 关系：SRE 关注可靠性目标(SLO/错误预算)，混沌工程是达成 SLO 的手段之一——用实验验证系统在故障下仍能维持 SLO，消耗错误预算时用混沌发现脆弱点改进。混沌工程不是 SRE 的全部，但成熟 SRE 体系必含混沌工程实践。

追问 2：如何说服业务团队在生产环境做混沌实验？

关键论点：① 不在生产实验，故障早晚会真实发生——与其被动等故障暴露脆弱点，不如主动受控发现；② 爆炸半径可控——小范围+自动中止+非高峰，风险可控；③ 渐进式推进——先非生产，团队建立信心后再生产单实例；④ 价值量化——每次发现的脆弱点都是潜在线上事故的预防，统计"实验发现的脆弱点数 vs 同期线上事故数"证明 ROI。Netflix、阿里等都是"先小规模试点 → 证明价值 → 全公司推广"。

本题聚焦 Kafka Exactly-Once 端到端工程化与事务协调器原理；基础机制（ISR/HW/acks 三档/幂等生产者原理）详见 C09.04，此处不重复展开。

考察分布式消息队列的可靠性设计与一致性语义的架构能力。核心回答：Kafka 通过分区副本机制 + ISR 集合 + Leader 选举保障高可用；通过幂等生产者 + 事务 API + 消费者位移原子提交实现 Exactly-Once 语义。需厘清副本同步机制、HW/LEO 水位、以及幂等号段与事务协调器的工作原理。

阶段 1：单分区单副本。早期消息队列（ActiveMQ）主从或单节点，故障即丢消息或不可用。

阶段 2：Kafka 分布式日志（2011）。LinkedIn 开源 Kafka，以分布式提交日志（Distributed Commit Log）为核心——分区多副本、Leader-Follower 同步、消费者拉取模式。高可用靠副本，高性能靠顺序写盘与零拷贝。

阶段 3：Exactly-Once 支持（0.11+）。引入幂等生产者（Idempotent Producer）与事务 API（Transactions），解决"生产者重试导致重复"与"跨分区原子写入"问题。配合消费者位移事务提交，实现端到端 Exactly-Once。

阶段 4：KRaft 模式（2.8 引入预览，3.3 生产就绪，4.0 移除 ZK）。去除 ZooKeeper 依赖，用自研 Raft 协议管理元数据，降低运维复杂度、提升控制器性能与一致性（具体时间线见下方"扩展补全"）。

ISR/HW/acks 基础机制见 C09.04，此处仅推导 Exactly-Once 的进阶设计。

Exactly-Once 三要素：

事务协调器与两阶段提交：Kafka 事务引入Transaction Coordinator（事务协调器）组件，每个 Broker 上运行一个协调器实例，职责是维护事务状态与写入事务日志（特殊内部 Topic __transaction_state）。事务生命周期：

• 阶段 1：BEGIN——生产者调用 initTransactions() 后分配 PID，beginTransaction() 向协调器注册事务。
• 阶段 2：提交准备——生产者通过 send() 将消息写入目标分区（消息被标记为事务性），随后调用 commitTransaction() 向事务协调器发起结束事务（EndTxn）请求，由协调器统一决策提交或中止。
• 阶段 3：COMMIT/ABORT——协调器先在内部事务主题 __transaction_state 记录最终状态，再向各参与分区写入事务控制标记（Commit 或 Abort 控制批次）；消费者（isolation.level=read_committed）会过滤掉 Abort 标记的消息；任意环节失败协调器广播 Abort，保证原子性。

Exactly-Once 边界与退化：Kafka 事务仅保证Kafka 内部 Topic 之间的原子性，跨外部系统（如数据库写入、Redis 更新、调用外部 HTTP 接口）时 Exactly-Once 语义会退化，需分层兜底：

• 跨数据库写操作（非 Kafka 事务）：DB 写不在 Kafka 事务协调器管辖范围内，Exactly-Once 退化为业务层幂等——为每条消息分配唯一业务 ID（如订单号+流水号），DB 表建唯一索引或用 Redis 去重 Set 防重复写入。
• 与 DB 双写一致性：Kafka 消息 + DB 事务无法原子提交，需引入Outbox Pattern + CDC：业务只写 DB 事务（业务表 + outbox 消息表在同一本地事务），Debezium/Canal 订阅 outbox 表的 binlog 异步投递到 Kafka，保证 DB 成功则消息必出，DB 回滚则消息不出，避免双写不一致。
• 调用外部 HTTP 接口：外部接口无事务保障，必须依赖接口幂等设计（如请求携带 X-Request-Id，服务端缓存已处理 ID 短时间去重）+ 失败重试 + 死信队列人工补偿。

高可用配置最佳实践：

# producer 高可靠配置
props.put("acks", "all");                 # ISR 全部确认
props.put("retries", 3);                # 失败重试
props.put("enable.idempotence", "true"); # 开启幂等
props.put("max.in.flight.requests.per.connection", 5); # 管道化，幂等下可>1

# broker 副本配置
replication.factor=3                   # 三副本
min.insync.replicas=2                  # acks=all 时至少 2 个 ISR 确认
unclean.leader.election.enable=false    # 禁止非 ISR 副本竞选 Leader，防丢消息

事务消费者模式：

// 消费-转换-生产事务： exactly-once 流处理
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(consumerProps);
KafkaProducer<String, String> producer = new KafkaProducer<>(producerProps);

// initTransactions 前提：producerProps 必须配置 transactional.id 且 enable.idempotence=true（见上方配置）
producer.initTransactions();
consumer.subscribe(Arrays.asList("input-topic"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    if (!records.isEmpty()) {
        producer.beginTransaction();
        for (ConsumerRecord<String, String> r : records) {
            producer.send(new ProducerRecord<>("output-topic", transform(r)));
        }
        // 将消费位移作为事务的一部分提交：需按分区构造 OffsetAndMetadata 映射
        // 注意 Consumer.position() 只接收单个 TopicPartition，无 Collection 重载，必须逐个分区取位
        // 需 import java.util.Map / org.apache.kafka.clients.consumer.OffsetAndMetadata / org.apache.kafka.common.TopicPartition
        Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
        for (TopicPartition tp : consumer.assignment()) {
            offsets.put(tp, new OffsetAndMetadata(consumer.position(tp)));
        }
        producer.sendOffsetsToTransaction(offsets, consumer.groupMetadata());
        producer.commitTransaction();
    }
}

关键落地要点：① unclean.leader.election.enable=false，宁可不可用也不丢消息；② replication.factor >= 3，跨机架部署；③ 幂等 + acks=all 是生产基线；④ 消费者位移提交优先用自动提交简化，流处理场景用事务提交；⑤ 监控 ISR 收缩——ISR 掉出副本说明同步延迟或节点故障。

追问 1：Kafka 为何不实现 Raft 而选 ISR + HW 机制？

Kafka 的副本同步是异步拉取模型（Follower 主动拉取 Leader），而非 Raft 的多数派同步。原因是：① 吞吐优先——异步拉取不阻塞生产者，Leader 只需等本地落盘即可响应（acks=1），同步是后台行为；② 消费者只读 HW——未同步完成的日志对消费者不可见，一致性通过 HW 水位保证；③ Raft 的强同步会牺牲吞吐。但 KRaft（元数据管理层）用 Raft，因为元数据量小、强一致要求高。

追问 2：Exactly-Once 的代价与适用场景？

Exactly-Once 有显著性能开销：① 幂等需要 Broker 维护 PID-SeqNum 状态；② 事务需要两阶段提交 + 事务日志。适用场景：金融交易、订单状态流转、对账系统等不能容忍重复的场景。对于日志采集、监控指标等可容忍 At-Least-Once + 下游去重的场景，不必用事务，避免性能损失。

补齐 Kafka 控制平面（Controller）的完整链路：ZK 时代 Controller 选举 → KRaft 去 ZK → leader epoch 数据安全 → ISR 伸缩与选举，这是从"会用 Kafka"到"懂 Kafka"的分水岭。

• ZooKeeper 模式下的 Controller 选举：所有 Broker 启动时在 ZK 的 /controller 路径创建临时节点，第一个创建成功的 Broker 成为 Controller；Broker 宕机或会话超时，临时节点消失，其余 Broker 监听 /controller 的 Watch 事件并重新抢注。Controller 职责：分区 Leader 选举、副本分配与迁移、ISR 变更、分区重平衡。痛点：Controller 依赖 ZK，ZK 集群故障会导致 Controller 无法选举、元数据不可用。
• KRaft 模式（Kafka 2.8 引入，3.x 推荐，4.0 起强制）：彻底移除 ZooKeeper，由 3+ 个 Controller 节点组成 Raft 集群；Active Controller 负责元数据管理与对外服务，Standby Controller 通过 Raft 复制元数据做热备，Leader 故障后自动接管。元数据不再存 ZK，而是写入内部 Topic __cluster_metadata（多副本存储）。优势：减少外部依赖、Controller 切换从秒级降到毫秒级、元数据操作延迟从秒级降到毫秒级、与数据面协议统一（都是日志复制）。
• Leader Epoch 机制：每个 Partition 维护单调递增的 leader epoch 号，Leader 每次切换时 epoch + 1。Follower 同步时携带自己记录的 epoch，Leader 若发现 Follower 的 epoch 落后，会通过 LeaderEpochRequest 告知 Follower 应截断的位点，防止 Follower 恢复后"回退"到低于 Leader 的日志位点。解决问题：旧机制仅靠 high watermark 截断，存在误导截断（可导致已提交数据丢失）风险；epoch 机制让截断判断基于 Leader 权威记录，杜绝误截。
• ISR 伸缩与 Leader 选举关系：副本落后 Leader 超过 replica.lag.time.max.ms（默认 30s）即被移出 ISR；追平后重新加入。Leader 选举优先从 ISR 内选（保证不丢已提交数据）；ISR 为空时，若开启 unclean.leader.election.enable=true（默认 false）才允许从非 ISR 副本选 Leader（会有数据丢失风险）。生产建议保持默认 false：宁可短暂不可用，也不丢数据，与 acks=all + min.insync.replicas=2 组合成完整的高可用数据安全基线。

上线门禁：积压/lag、幂等与重试、容量与分区模型一致。表达提纲：语义边界→中间件证据→运维剧本。

本题聚焦 C10.02/C10.03/C10.09 未覆盖的增量——网关层与服务层限流协同、AI 流量治理(Token 限流/MCP 接口配额)、网关扩展插件；基础限流算法、熔断状态机、Spring Cloud Gateway 实现、灰度染色原理详见 C10.03/C10.02/C10.09。其中 SC Gateway 过滤器链与转发末端（NettyRoutingFilter，order=LOWEST_PRECEDENCE）以 C10.20 为准，本卡聚焦限流/熔断/灰度的通用设计，不重复展开产品实现细节。

考察API 网关作为微服务流量入口的统一治理能力。核心回答：API 网关本质是反向代理 + 协议转换 + 流量控制 + 可观测性的聚合层。需厘清限流（Rate Limiting）的算法选型、熔断（Circuit Breaker）的状态机与恢复策略、以及灰度发布（Canary）的流量染色与路由机制。

阶段 1：Nginx 反向代理。静态配置 upstream，负载均衡（轮询/权重/ip_hash），无动态服务发现与熔断能力。

阶段 2：网关 1.0（Spring Cloud Gateway / Zuul / Kong）。动态路由（对接注册中心）、过滤器链（鉴权/限流/日志）、插件化扩展。Zuul 1.x 阻塞 IO，Gateway 基于 WebFlux 非阻塞。

阶段 3：网关 2.0（Envoy / Traefik）。Service Mesh 边车或独立网关，支持 gRPC/HTTP2、动态配置（xDS 协议）、WASM 插件、更精细的流量管理。

阶段 4：云原生网关（Ingress Controller / APISIX / Higress）。K8s 原生集成、MCP（Model Context Protocol）支持、AI 流量管理（Token 限流、模型路由）、Serverless 弹性。

WASM 插件的真实边界：网关插件做跨实现可移植，靠的是 Proxy-Wasm ABI（Envoy 生态主导），因此「一份插件跑遍所有网关」只在支持该 ABI 的实现上成立——NGINX / APISIX 的原生插件、Spring Cloud Gateway 的 GlobalFilter 与 WASM 插件互不通用。生产选型要核对三件事：① 目标网关是否声明支持 Proxy-Wasm 及其 ABI 版本；② 插件位于请求热路径，需实测单请求额外延迟与内存上限，宿主侧要为其预留资源；③ 插件与网关版本需绑定升级，ABI 不兼容会直接导致网关启动失败。若团队本无跨网关复用需求，用宿主语言写原生插件在性能与可调试性上通常更优。

基础限流算法（计数器/滑动窗口/令牌桶/漏桶）对比、熔断三态机（Closed/Open/Half-Open）原理、灰度发布流量染色与路由机制详见 C10.03/C10.02/C10.09，此处仅展开 10.x 未覆盖的增量设计。

网关层 vs 服务层限流协同：两层限流不是重复建设，而是纵深防御，定位与维度不同：

• 网关层：入口级粗控——维度为 API 路径、AppKey、IP、租户 ID，阈值按集群总容量设定（如单 API 10万 QPS），目标是拦截恶意/突发流量，防止过载流量穿透到服务层。实现通常用 Redis 分布式令牌桶（跨网关实例共享计数）。
• 服务层：实例级精控——维度为接口、线程池、DB 连接池、下游依赖资源，阈值按单实例容量设定（如某接口单实例 500 QPS），目标是保护自身不被拖垮。实现通常用本地令牌桶（Sentinel/Resilience4j 内存计数器，避免跨实例网络开销）。
• 协同防漏：网关限流阈值 = 服务实例数 × 单实例限流阈值 × 冗余系数（1.2~1.5），留足弹性但避免漏限流。当服务层因异常触发熔断时，网关层通过健康检查/主动探测感知，快速摘除异常实例，路由到健康节点。

AI 流量治理：大模型时代流量特征从"QPS 驱动"变为"Token 驱动 + 流式长连接"，传统 QPS 限流不适用，需三类扩展能力：

• 按 Token 而非 QPS 限流：模型推理成本与输入输出 Token 数正相关（GPT-4 每 1K Token 成本是普通 API 的百倍）。网关需识别请求体中的 max_tokens 字段估算消耗，或拦截响应流式 chunk 累加实际输出 Token，按Token 速率（如 10万 Tokens/分钟/用户）限流，而非单纯 QPS。
• MCP 工具接口独立配额：MCP（Model Context Protocol）网关承载模型调用外部工具（代码执行/SQL 查询/文档检索）的流量，不同工具的成本与风险差异极大（如代码沙箱执行比文档检索贵 10 倍、写数据库工具需严格权限）。需为每个 MCP Tool 独立配置限流配额、熔断阈值、权限白名单，而非按模型 API 统一限流。
• 流式请求的背压传递：大模型 SSE（Server-Sent Events）流式输出时，响应可能持续 10~60 秒，传统连接池/线程池模型会被长连接占满。网关需支持：① 请求级并发数限制（而非 QPS），按用户/租户限制同时进行中的流式请求数；② 背压传递——客户端消费慢（TCP 窗口满）时，网关暂停从模型服务拉取 chunk，避免内存堆积；③ 超时分段控制——首 token 超时（如 10s 未收到首包快速失败）与总流式时长超时（如 120s 强制截断）分离。

Spring Cloud Gateway Redis 令牌桶限流代码、Sentinel 熔断规则配置、灰度发布 Header 染色方案详见 C10.03/C10.02/C10.09，此处补充 AI 网关增量工程实践。

AI 网关按 Token 限流示例（APISIX/自定义 Plugin 伪代码）：

-- 接入层拦截：累加输入+输出 Token，按用户维度做令牌桶限流
local function token_rate_limiting(conf, ctx)
    local user_id = ctx.var.http_x_user_id or "anonymous"
    local key = "token_limit:" .. user_id

    -- 1. 请求体预解析：估算 max_tokens 作为预扣减依据
    local req_body = core.request.get_body()
    local max_tokens = req_body and json.decode(req_body).max_tokens or 2048
    local ok, _ = limit_req:check(key, max_tokens, conf.tokens_per_minute / 60, conf.burst)
    if not ok then
        return 429, "Token quota exceeded, please retry later"
    end

    -- 2. 响应阶段：拦截流式 chunk，累加实际 output token，修正计数
    ctx.token_count = 0
    local function log_chunk(chunk)
        for line in string.gmatch(chunk, "[^\n]+") do
            if string.sub(line, 1, 6) == "data: {" then
                local usage = json.decode(string.sub(line, 7)).usage
                if usage then
                    ctx.token_count = ctx.token_count + (usage.completion_tokens or 0)
                end
            end
        end
    end
end

MCP 工具接口独立配额：网关按 MCP Server + Tool Name 粒度配独立限流 Key，而非按模型 API 共享：

# MCP 网关限流规则示例（YAML）
# 高风险/高成本工具配额收紧，低风险工具放宽
mcp_tools_quota:
  - tool: "sql_query"                # 写数据库：严格限制
    per_user: 60 requests/hour         # 60 次/用户/小时
    concurrency: 2                      # 同时进行中不超 2 个
    require_whitelist: true               # 仅白名单用户可用
  - tool: "code_executor"            # 代码沙箱：成本高
    per_user: 300 requests/hour
    concurrency: 5
  - tool: "document_search"          # 文档检索：放宽
    per_user: 6000 requests/hour
    concurrency: 20

流式请求并发数 + 背压控制要点：① 对 SSE/WebSocket 接口配置Per-User In-Flight Request Limit（如免费用户同时最多 3 个流式请求，付费用户 10 个），而非 QPS；② 网关层开启 TCP TCP_NODELAY 并监听 write_buffer_high_watermark，写缓冲区满时暂停向上游拉取数据；③ 首 Token 超时（TTFT）设 10s、流式总时长设 120s，超过返回 504 并打审计日志。

追问 1：网关层限流与服务层限流如何协同？

网关层限流做粗粒度全局防护（按 API/用户/IP），防止恶意流量打到服务层；服务层限流做细粒度自我保护（按接口/资源/租户）。两层协同：网关限流配置较宽（如 10万 QPS），服务层按自身容量设更严格阈值（如 1万 QPS）。当某服务实例异常时，服务层熔断快速失败，网关层仍可将流量路由到健康实例。

追问 2：Spring Cloud Gateway 与 Envoy 的选型差异？

Spring Cloud Gateway 适合Java 技术栈、快速开发、与 Spring Cloud 生态集成的场景，开发成本低但性能受 JVM 限制。Envoy 适合多语言栈、高性能、云原生/K8s场景，C++ 编写性能更高，xDS 动态配置能力强，但运维复杂度高。趋势：云原生环境倾向 Envoy/APISIX，传统 Spring 生态倾向 Gateway。

考察分布式环境下定时任务的可靠执行与资源协调能力。核心回答：分布式调度需解决任务分片、集群竞争执行、故障转移、幂等性、以及调度与执行的解耦四大问题。本质是 CAP 在调度场景的体现——高可用与精确执行不可兼得时，优先保证至少执行一次 + 业务幂等。各框架运维成熟度、社区现状与详细对比见 C11.21（两卡互补，不重复展开）。

阶段 1：单机定时器（Timer / ScheduledThreadPool）。单 JVM 内执行，集群部署时会重复执行，无高可用。

阶段 2：数据库悲观锁互斥（早期分布式）。多节点抢锁（SELECT FOR UPDATE），抢到才执行。简单但性能差、无分片、无监控。

阶段 3： Quartz + JDBC JobStore。集群模式通过数据库行锁实现互斥，支持持久化、失败重试、错过触发补偿。但依赖 DB、扩展性差。

阶段 4：Elastic-Job / XXL-JOB / PowerJob。Elastic-Job（当当）基于 ZooKeeper 分片与选举；XXL-JOB（大众点评）中心化调度器 + 执行器注册；PowerJob 支持复杂工作流与 MapReduce 分片。

阶段 5：云原生调度（K8s CronJob / Serverless 定时触发）。K8s CronJob 按 Cron 表达式创建 Pod 执行任务；云函数定时触发（AWS Lambda / 阿里云 FC），无服务器运维，但受冷启动延迟限制。

分布式调度四大核心问题：

调度模型对比：

• 中心化调度（XXL-JOB）：调度中心统一触发，执行器注册上报。优势：调度逻辑集中、管理界面完善、分片策略简单。劣势：调度中心是单点（需集群化）、网络抖动影响触发精度。
• 去中心化调度（Elastic-Job）：各节点通过 ZK 选举 Leader 协调分片，本地定时器触发。优势：无中心瓶颈、触发精度高。劣势：依赖 ZK、分片重平衡复杂、无统一可视化。
• 混合调度（PowerJob）：支持单机/广播/Map/MapReduce 多种执行模式，复杂 DAG 工作流编排。

XXL-JOB 分片执行示例：

@XxlJob("orderCheckJob")
public ReturnT<String> execute(String param) {
    // 分片参数：当前分片序号、总分片数
    int shardIndex = XxlJobHelper.getShardIndex();
    int shardTotal = XxlJobHelper.getShardTotal();

    // 按 user_id 取模分片，各节点处理自己的数据
    List<Order> orders = orderMapper.selectPendingOrders(shardIndex, shardTotal);
    for (Order order : orders) {
        process(order);
    }
    return ReturnT.SUCCESS;
}

ShedLock 轻量级分布式锁（Spring 集成）：

@Scheduled(cron = "0 0/5 * * * ?")
@SchedulerLock(name = "reportGeneration", lockAtMostFor = "10m", lockAtLeastFor = "1m")
public void generateReport() {
    // 只有抢到锁的节点执行，lockAtMostFor 防止节点崩溃后锁不释放
    // lockAtLeastFor 防止任务执行时间过短导致多节点重复执行
}

选型建议：① 简单定时 + 可视化：XXL-JOB（社区活跃、文档完善、开箱即用）；② 海量数据分片处理：Elastic-Job（分片策略灵活、执行效率高）；③ 复杂工作流编排：PowerJob / Apache DolphinScheduler；④ Serverless/云原生：K8s CronJob / 云函数定时触发；⑤ 已有 Spring 生态简单需求：ShedLock + @Scheduled 足够。

追问 1：调度框架的"错过触发（Misfire）"如何处理？

当节点宕机或线程池满导致定时点未执行时，Quartz 提供 Misfire 策略：立即补执行（WITH_IGNORE_MISFIRES）、放弃错过（DO_NOTHING）、下次触发点执行（FIRE_AND_PROCEED）。选择取决于业务：对账类任务选补执行，统计类任务可放弃。XXL-JOB 通过阻塞处理策略（单机串行/丢弃后续/覆盖之前）控制。

追问 2：任务执行超时但节点失联，如何防止重复执行？

这是分布式调度的经典难题。方案：① 执行前写"执行中"状态 + 心跳续期，其他节点看到"执行中"不抢；② 超时后由监控线程标记为失败，再允许重新调度；③ 业务层幂等兜底——无论调度层如何保证，业务必须支持重复执行无副作用（唯一索引/状态机校验）。

这道题考察对"搜索引擎为何不能直接用 MySQL 的 LIKE/B+树，而要设计独立的倒排索引与分布式架构"的理解。核心回答三个问题：① ES 为何用倒排索引（Inverted Index）而非 B+树——前者按词项定位文档，O(1) 级命中，后者按主键范围扫描，全文检索需全表扫描；② 如何平衡全文检索与结构化查询——倒排索引负责分词检索，Doc Values 列式存储负责排序/聚合；③ 分布式分片（Shard）如何保证水平扩展——路由公式 hash(routing) % number_of_primary_shards 将文档固定到主分片，Primary/Replica 副本保证高可用。

Lucene（1999，Doug Cutting）：单机全文检索库，提供倒排索引、分词、布尔查询能力，但本身无分布式、无 HTTP 接口，需嵌入 Java 应用。

Solr（2004，基于 Lucene）：在 Lucene 之上封装企业级搜索服务，提供 HTTP 接口、Schema 管理、主从复制，成为企业搜索主流，但分布式扩展能力较弱（早期 SolrCloud 较晚才成熟）。

Elasticsearch（2010，Shay Banon）：同样基于 Lucene，但从一开始就为分布式设计——内置集群发现、分片自动路由、副本高可用、REST + JSON 接口，开箱即用，迅速取代 Solr 成为主流。

ES 7.x/8.x（2019—至今）：引入向量检索（dense_vector + KNN）支撑语义搜索、SQL 查询接口、安全默认开启（TLS + 认证）、新类型组件提高聚合性能，向"搜索 + 分析 + 向量数据库"综合体演进。

演进驱动力：① 分布式水平扩展——单机 Lucene 无法支撑 PB 级数据，ES 用分片+副本解决；② 开箱即用——从 Solr 的繁琐 Schema 配置到 ES 的动态 Mapping + REST 接口；③ 实时性——从 Solr 的近实时（NRT）到 ES 的 1 秒 Refresh；④ AI 时代向量检索——传统倒排索引无法做语义相似度，dense_vector + KNN 补齐语义搜索能力。

ES 版本演进时间线（1.x→8.x）：

• ES 1.x（2014）：新增 Aggregation（聚合）框架、Watcher 告警；分片策略初定为"一个类型默认 5 主分片"。
• ES 2.x（2015）：Query DSL 向 Query-bool 统一，新增 Pipeline Aggregation；推出 Ingest 预处理管道。
• ES 5.x（2016）：默认 5 主分片、引入 composite 聚合思想前身；移除 site plugin（kopf 等），强化 REST/安全栈（X-Pack 商业化整合）。
• ES 6.x（2017）：明确"一个 index 只保留一个 type"，为 7/8.x 移除 type 铺路；新增模板变量、时序索引治理（未来 ILM 前身），字段上限放宽。
• ES 7.x（2019）：正式弃用 mapping type（7.0 标记、8.0 彻底移除）；默认主分片改为 1（6.x 的 5 分片对多数场景过于碎片化）；6.8/7.1 起 X-Pack 安全（TLS + 基础认证）在 Basic 授权下免费；7.7 起内置 dense_vector + 近似 KNN。
• ES 8.x（2022）：安全默认开启（TLS + 内置用户认证）、mapping type 彻底移除；8.8 引入 RRF（Reciprocal Rank Fusion）做词法 + 向量混合检索；8.11 起 ES|QL 管道式查询预览，朝"一站式搜索 + 分析"演进。

亮点一句话："从 6.x 的 5 分片到 7.x 的 1 分片、从 type 多类型到单索引、再到 8.x 安全默认开启 + RRF 混合检索"——版本演进本质是"更简单、更默认安全、更向量化"。

倒排索引三要素：

• Term Dictionary（词项字典）：分词后的所有词项排序存储，支持二分查找定位。内存中放不下时落到磁盘。
• Term Index（FST 压缩）：用 FST（Finite State Transducer）压缩 Term Dictionary 的前缀/后缀，常驻内存，O(len) 定位词项在字典中的位置，极大降低内存占用。
• Posting List（倒排表）：每个词项对应的文档 ID 列表，用 Frame of Reference（FOR）压缩 + Roaring Bitmap做联合查询，支持 skip 跳转加速。

Segment 不可变 + 写入三阶段：Lucene 把索引切成多个不可变 Segment。写入先写内存 Buffer + Translog，Refresh（默认 1s）把 Buffer 生成新 Segment 进 Page Cache 可被搜到（近实时），Flush把 Segment 落盘并清空 Translog（持久化），Merge后台把小 Segment 合并成大 Segment 减少段数量与删除标记。

分片与路由：索引被拆为 N 个主分片（Primary），每个主分片可有 R 个副本（Replica）。文档路由公式：shard = hash(routing) % number_of_primary_shards，默认 routing 用文档 _id。主分片数创建后不可变（因为路由公式依赖它），扩容只能靠 reindex 新建索引。

集群角色（ES 7.9+）：

• Master：维护集群元数据（索引/分片分配），不存数据，需奇数个防脑裂。
• Data Node：存储 Segment、执行 CRUD 与查询，资源消耗大户。
• Coordinating Node：接收请求、分发到分片、汇总结果（路由 + Gather/Reduce）。
• Ingest Node：写入前对文档做预处理（管道 enrich/转换）。

Spring Data Elasticsearch 整合示例：

// 1. 文档映射：@Document 指定索引名与分片数
@Document(indexName = "product", shards = 3, replicas = 1)
public class ProductDoc {
    @Id
    private String id;
    @Field(type = FieldType.Text, analyzer = "ik_max_word")
    private String name;          // 分词全文检索
    @Field(type = FieldType.Keyword)
    private String category;     // 不分词，用于聚合/精确匹配
    @Field(type = FieldType.Double)
    private Double price;        // 排序/范围查询
}

// 2. 继承 ElasticsearchRepository 即可获得 CRUD
public interface ProductRepository extends ElasticsearchRepository<ProductDoc, String> {
    Page<ProductDoc> findByCategory(String category, Pageable pageable);
}

// 3. 深度分页用 search_after 替代 from+size，避免 OOM
NativeSearchQuery query = new NativeSearchQueryBuilder()
    .withQuery(QueryBuilders.matchQuery("name", "手机"))
    .withSort(SortBuilders.fieldSort("price").order(SortOrder.ASC))
    .withSearchAfter(Collections.singletonList(lastPrice)) // 上一页最后一条的排序值
    .build();

索引设计要点：① 分片数估算——单分片建议 30~50GB，分片数 = 数据量GB / 30 向上取整，过小导致段碎片、过大导致查询扇出多；② Mapping 禁用动态推断——生产环境 "dynamic": "strict"，避免脏字段污染 Mapping；③ Keyword vs Text——需聚合/排序/精确匹配用 Keyword，全文检索用 Text + 分词器；④ 深度分页——from + size 协调节点需拉取 from+size 条数据排序，超过 10000 默认拒绝，用 search_after（基于排序值游标）或 Scroll（快照遍历）替代。

追问 1：ES 为何是"近实时"而非"实时"，Refresh 默认 1 秒的设计权衡是什么？

写入先到内存 Buffer，此时搜不到。Refresh 把 Buffer 生成新 Segment 进操作系统 Page Cache（无需 fsync 落盘），文档即可被检索，默认 1 秒一次。设计权衡：Refresh 越频繁，Segment 越多，查询时要合并更多段、Merge 压力越大；Refresh 越慢，数据可见性延迟越高。1 秒是搜索场景"准实时 + 写入吞吐"的折中。对写入吞吐优先的日志场景可调大（如 30s），对可见性敏感可调小或手动 refresh=false 写完后主动调一次。

追问 2：写入数据如何保证不丢？Translog 与 Flush 的关系？

写入同时写内存 Buffer 与 Translog（Write-Ahead Log，落盘 fsync）。Refresh 只让数据可搜但不落盘。当 Translog 达到阈值（默认 512MB）或定时触发 Flush：把内存 Buffer 生成 Segment 并 fsync 落盘，清空 Translog。即使 Refresh 后的 Page Cache 数据因宕机丢失，重启后也能用 Translog 重放未 Flush 的写入，保证数据不丢。因此 Translog 的 fsync 策略（每次写/每 5s/请求结束）决定数据可靠性级别。

这道题考察对"微服务间高性能通信为何要绕开 REST/JSON"的底层理解。核心回答三个问题：① 为何 Protobuf 比 JSON 快——二进制紧凑编码（varint + field tag），无需分隔符与引号，解析是字段定位而非文本解析；② HTTP/2 多路复用如何降延迟——单 TCP 连接并发多个请求流，HPACK 头压缩消除冗余；③ gRPC 四种调用模式的适用场景——Unary 一元、Server Stream 服务端流、Client Stream 客户端流、Bidi 双向流，分别对应普通 RPC、大结果推送、批量上报、实时双向交互。

CORBA / SOAP（2000 年前后）：早期 RPC 方案，基于 IIOP/SOAP 协议，重量级、强耦合、跨语言麻烦（需 IDL + 复杂中间件），逐步被淘汰（已被 REST/gRPC 趋势替代）。

REST / JSON（2010 年代主流）：轻量、可读性好、跨语言、与 HTTP/1.1 天然契合，成为互联网标配。但 JSON 文本解析慢、Header 冗余、HTTP/1.1 单连接一次一请求（队头阻塞），性能瓶颈明显。

gRPC（2015，Google 开源）：基于 HTTP/2 + Protobuf，定位高性能通用 RPC 框架。多语言 Stub 自动生成、双向流、强类型契约，迅速成为云原生服务间通信首选（CNCF 项目大量采用）。

gRPC-Web / Connect（2018+）：浏览器原生不支持 HTTP/2 Trailer，gRPC-Web 通过代理转译让前端可调 gRPC；Buf Connect 重新设计协议，更贴合 HTTP 语义，降低网关复杂度。

演进驱动力：① 性能——微服务化后调用链路变长，JSON+HTTP/1.1 的文本解析与队头阻塞成为瓶颈；② 跨语言契约——微服务多语言并存，需要 IDL 生成强类型 Stub；③ 流式场景——实时音视频、推送、批量上报需要双向流，REST 的请求-响应模型无法表达；④ 云原生生态——Envoy/Istio 原生支持 gRPC，成为 Service Mesh 的事实通信协议。

Protobuf / gRPC 版本演进时间线：

• Protobuf v2（2008）：Google 首个正式 IDL，引入 required/optional/repeated 字段与各语言代码生成，解决跨语言序列化。
• Protobuf v3（2016）：删除 required、标量字段默认值规一为 0、新增 Any/Oneof/Map 与语义精简；成为 gRPC 默认 schema。
• gRPC 1.0（2015-2016）：Google 开源，Java/Go/C++ 等首发多语言，基于 HTTP/2 + Protobuf，定义四调用模式。
• gRPC 1.x 能力增强（2016+）：补充 Server Reflection（反射发现 proto）、Health Checking、Retry 策略（客户端自动重试）、Interceptor 拦截器插件化、一致性哈希/权责负载均衡。
• gRPC-Web（2018）：浏览器无法直接处理 HTTP/2 Trailer 与长连接，经 Envoy 代理转译让前端可调 gRPC；Buf Connect（2019+）重新设计协议更贴合 HTTP 语义。
• xDS 与无 stub 治理（2019+）：gRPC 与 Envoy/Istio 的 xDS 协议打通，实现动态服务发现、负载均衡与流量治理，成为 Service Mesh 事实标准。

亮点一句话："从 protobuf2 的 required/optional 到 proto3 的 Any/Oneof、从 gRPC-Web 补浏览器短板到 xDS 进 Service Mesh，版本演进本质是'更精简、更可观测、更下沉到基础设施'"。

Protobuf 二进制编码：每个字段用 (field_number << 3) | wire_type 的 tag 标识，值用 varint（变长整数，小数字 1 字节）编码。无字段名、无引号、无分隔符，体积比 JSON 小 30%~50%，解析只需按 tag 跳读，无需文本 tokenize。

HTTP/2 三大加速：① 多路复用（Multiplexing）——单 TCP 连接并发多个 Stream，每个请求一个 Stream ID，彻底解决 HTTP/1.1 队头阻塞；② HPACK 头压缩——静态表 + 动态表 + Huffman 编码，重复 Header 只传索引；③ 流控与流优先级——HTTP/2 提供流级/连接级流量控制（滑动窗口），gRPC 的背压（如消费方慢导致发送暂停）正是依赖该机制而非应用层；另支持流优先级调度帧。

gRPC 四种调用模式：

• Unary（一元）：一请求一响应，等同普通 RPC，适合大多数业务调用。
• Server Streaming：一请求多响应，服务端分批发送，适合大结果集分页、订阅推送。
• Client Streaming：多请求一响应，客户端批量上传，适合埋点上报、批量写入。
• Bidirectional Streaming：双向流，适合实时聊天、协同编辑、双向心跳。

Stub 生成：通过 protoc 编译 .proto 文件，生成各语言的客户端 Stub（序列化 + HTTP/2 调用封装）与服务端接口基类，调用方像调本地方法一样发起远程调用，屏蔽网络细节。

1. Protobuf IDL 定义（.proto）：

syntax = "proto3";
package order.v1;
option java_package = "com.example.order.api";
option java_multiple_files = true;

service OrderService {
  // Unary：创建订单
  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);
  // Server Stream：查询订单流水
  rpc StreamOrders(StreamOrdersRequest) returns (stream OrderRecord);
}

message CreateOrderRequest {
  string user_id = 1;
  string product_id = 2;
  int32 quantity = 3;
}
message CreateOrderResponse {
  string order_id = 1;
  bool success = 2;
}

2. protobuf-maven-plugin 生成 Stub：pom 引入 protobuf-maven-plugin + protoc 二进制，mvn generate-sources 自动生成 Java 类。再配合 grpc-spring-boot-starter（如 LogNet 或 yidongnan），用 @GrpcService 暴露服务、@GrpcClient 注入客户端。

3. 拦截器（日志/鉴权/追踪）：

public class AuthServerInterceptor implements ServerInterceptor {
    @Override
    public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(
            ServerCall<ReqT, RespT> call, Metadata headers,
            ServerCallHandler<ReqT, RespT> next) {
        String token = headers.get(Metadata.Key.of("authorization", Metadata.ASCII_STRING_MARSHALLER));
        if (token == null || !verify(token)) {
            call.close(Status.UNAUTHENTICATED.withDescription("token无效"), new Metadata());
            return new ServerCall.Listener<ReqT>() {};
        }
        // 注入 traceId 到 MDC，串联链路追踪
        MDC.put("traceId", headers.get(TRACE_KEY));
        return next.startCall(call, headers);
    }
}

追问 1：Protobuf 如何保证向后/向前兼容？

Protobuf 靠字段编号而非字段名定位，兼容规则：① 新增字段用新编号，旧客户端忽略未知字段（unknown fields 保留），向前兼容；② 删除字段需保留编号不复用（用 reserved 标记），避免新旧端误读；③ 字段类型需兼容（如 int32→int64 可放宽，反过来会截断）；④ proto3 默认字段无 presence（无 optional 语义）——普通标量字段无法区分"未设"与"默认值"，反序列化后两者等价；如需判定需声明 显式 optional 关键字（protobuf 3.12+ 重新引入，行为同 proto2），才会生成 hasXxx() 方法。核心：编号是契约的稳定锚点，改名不影响。

追问 2：gRPC 是长连接，如何做负载均衡？

HTTP/2 长连接使传统 L4 负载均衡（每次请求重新建连）失效。方案分两层：① 客户端侧 LB（内置）——gRPC 提供 pick_first（默认连一个）与 round_robin 策略，客户端直接从解析到的多个后端地址轮询，无中间代理层延迟低；② 服务端代理 LB（Envoy xDS）——客户端只连 Envoy，Envoy 通过 xDS 动态获取后端实例并做加权/最少连接调度，配合健康检查与熔断，是 Service Mesh 的标准做法。注意 DNS 缓存会导致实例上下线感知延迟，生产用 xDS 主动推送。

这道题考察对"配置中心到底要解决什么问题，以及不同实现的架构权衡"的理解。核心回答：配置中心要解决动态推送、灰度发布、版本回滚、多环境隔离四大诉求，告别改配置要重启应用的痛点。Nacos 与 Apollo 的架构差异在于推送机制（Apollo 纯长轮询 vs Nacos 长轮询 + UDP 混合）与一致性模型（Nacos 同时支持 AP/CP，Apollo 强一致）。长轮询是"客户端定时拉 + 服务端 hold 住连接有变更才立即返回"的折中方案，平衡实时性与连接成本。

阶段 1：properties 硬编码 / 配置文件随包发布。配置改一次发一次版，环境间配置靠 profile 切换，无法动态调整。

阶段 2：DB 配置表 + 应用定时拉取。配置入库，应用启动加载 + 定时轮询。解决了发版问题，但实时性差、无推送、无灰度。

阶段 3：ZooKeeper 强一致配置。利用 ZK 的 Watch 机制做配置变更通知，实时性好、强一致。但 ZK 运维复杂、CP 模型在配置场景过重（配置更关注可用性而非强一致）。

阶段 4：Apollo（携程 2016 开源）。专为配置中心设计，长轮询推送 + 多环境 + 灰度发布 + 版本回滚，管理后台完善，Java 生态成熟。

阶段 5：Nacos（阿里 2018 开源）。配置中心 + 注册中心二合一，2.x 起 gRPC 长连接双向流推送（取代 1.x 长轮询+UDP），连接复用、状态精准、性能显著提升，支持 AP/CP 切换，与 Spring Cloud Alibaba 深度整合，云原生首选。

Nacos 2.0（2021）：通信模型从 HTTP 短连接长轮询升级为 gRPC 长连接；官方基准测试称连接管理与推送延迟较 1.x 有数量级（约 10x）提升，实际以官方与自身压测为准。

演进驱动力：① 动态推送——配置变更秒级生效无需重启；② 灰度与回滚——配置也要像代码一样可灰度、可回滚、可审计；③ 多环境隔离——Dev/Test/Prod 配置分离，避免误连；④ 运维简化——ZK 太重，需要更轻量、专注配置的方案；⑤ 注册配置合一——Nacos 把配置与发现合并，减少组件数量。

Apollo 长轮询机制：客户端定时（默认 1s 检测）向 Config Server 发起长轮询请求，服务端hold 住连接：若有配置变更立即返回变更的 namespace 列表，客户端再拉取具体配置内容；若无变更则保持连接到超时（默认 60s）后返回，客户端立即发下一次请求。本质是"服务端有变更才返回 + 客户端持续保活"，兼顾实时性与连接复用。

Nacos gRPC 长连接推送（2.x）/ 长轮询+UDP（1.x 兼容）：2.x 客户端通过 gRPC 长连接订阅配置，服务端变更时通过 gRPC 流主动推送；1.x 兼容模式下仍用长轮询+UDP（客户端长轮询，服务端变更时额外发 UDP 包做快速通知，UDP 丢失时长轮询兜底）。

配置灰度发布：按 IP 维度或标签维度指定部分实例先生效新配置，验证无误再全量推送。Apollo 内置灰度规则引擎，Nacos 通过命名空间 + 分组 + DataId 组合实现类似隔离。

多环境隔离：Apollo 用 Env（DEV/FAT/UAT/PRO）+ Cluster（机房）+ Namespace 三级隔离；Nacos 用命名空间（Namespace）+ 分组（Group）+ DataId 三级隔离，命名空间天然对应环境。

Nacos AP/CP 切换：

• 临时实例（AP）：客户端靠心跳维持，实例下线心跳超时自动剔除，AP 优先可用性，适合注册中心场景。
• 永久实例（CP）：服务端主动探测，实例信息持久化，变更走 Raft 协议强一致，适合需要精确一致的场景。

Spring Cloud Alibaba Nacos Config 动态刷新示例：

// 1. bootstrap.yml 声明 Nacos 配置源
spring:
  cloud:
    nacos:
      config:
        server-addr: ${NACOS_ADDR}
        namespace: ${NACOS_NS}      # 命名空间=环境隔离
        group: ORDER_GROUP
        data-id: order-service.yaml
        refresh-enabled: true

// 2. @RefreshScope + @Value 实现配置热更新
@RefreshScope
@Component
public class OrderConfig {
    @Value("${order.timeout:3000}")
    private int timeout;        // Nacos 改了 order.timeout，这里自动刷新

    @Value("${order.retry:3}")
    private int retry;
}

// 3. 监听配置变更事件，做自定义逻辑
@Component
public class ConfigChangeListener {
    @EventListener
    public void onChange(RefreshScopeRefreshedEvent event) {
        // 如重建线程池、刷新本地缓存等
    }
}

配置加密（Jasypt）：敏感配置（数据库密码、密钥）用 Jasypt 加密后存入 Nacos，客户端用密钥解密。Nacos 也内置配置加密插件（AES），在 DataId 标记 cipher- 前缀自动加解密。

版本管理与回滚：Apollo 内置历史版本，一键回滚到任意历史配置并记录操作人；Nacos 2.x 后也支持配置历史与回滚（保留 30 天），生产务必开启审计。变更前在测试命名空间验证，灰度后再全量。

追问 1：Nacos 为何能同时支持 AP 和 CP？

Nacos 区分临时实例与永久实例。临时实例由客户端发心跳保活，心跳断开即剔除，走 Distro 协议（AP）——各节点独立处理写请求再异步同步，优先可用性，适合服务注册（实例频繁上下线，临时不一致可接受）。永久实例由服务端主动探测，走 Raft 协议（CP）——写需多数派确认，强一致，适合数据库等持久化服务的注册。一套系统两种协议按实例类型分治，是 Nacos 的设计亮点。

追问 2：配置中心与 K8s ConfigMap 如何取舍？

ConfigMap 是 K8s 原生的配置卷，改 ConfigMap 后 Pod 挂载的文件会更新（但应用需自行 watch 或重启才能感知），优势是无额外组件、与 K8s 深度集成。配置中心优势在于动态推送（无需重启）、灰度发布、多环境统一管理、跨集群。取舍：纯 K8s 环境且配置变更少、可接受滚动重启，用 ConfigMap 足够；需要秒级动态生效、灰度、跨 K8s/非 K8s 混合部署，用配置中心。二者也可结合：ConfigMap 放启动参数，配置中心放运行期动态配置。

上面的原理层讲了长轮询的"是什么"，这里补Nacos 长轮询的源码级实现与 1.x→2.x 的演进细节，让回答从"背结论"升级为"讲机制"。

• 客户端长轮询机制（Nacos 1.x）：客户端通过 LongPollingRunnable 周期性发起 HTTP 长轮询请求到 /v1/cs/configs（携带已订阅 DataId 的 MD5 列表），请求超时设置 30s；服务端收到请求后校验配置 MD5——有变更立即返回新内容，无变更则把请求挂起（Servlet 3.1 AsyncContext 异步化）放入 allSubs 队列，同时注册超时定时器；配置发布时服务端遍历 allSubs，找到匹配的挂起请求并立即响应；30s 超时仍无变更则返回空结果，客户端拿到空结果后立即发起下一轮长轮询，形成"挂起-唤醒"循环。
• Nacos 2.x：gRPC 长连接替代长轮询：改用 gRPC Bidirectional Streaming，客户端与服务端建立持久长连接，服务端通过 gRPC Stream 主动推送（Push）变更，无需客户端轮询。优势：变更延迟从最长 30s 降到毫秒级；长连接复用大幅减少 HTTP 建连开销（官方基准测试称较 1.x 长轮询有数量级、约 10x 提升，具体以官方与自身压测为准）；连接状态可感知（断线可重连）。向后兼容：2.x 客户端连 1.x 服务端时自动降级为长轮询，保证升级平滑。
• MD5 校验机制（内容指纹去重）：客户端本地缓存已拉取配置的内容，并计算其 MD5，长轮询请求携带 DataId → MD5 映射列表；服务端用当前配置 MD5 与客户端上报值比对——一致说明客户端缓存已是最新，无需返回内容；不一致才返回完整新内容。这是一种"内容指纹"级的去重策略：大部分轮询"无变化"，传输的只是一个 MD5 列表而非全量配置，显著节省带宽与解析开销。
• 与 Apollo 推模型对比：Apollo 是 HTTP 长轮询 + 客户端定时拉取双保险（长轮询通知变更 namespace，客户端再拉内容，另维护兜底轮询）；Nacos 2.x 是 gRPC 双向流推送，延迟更低、连接开销更小，但引入了 gRPC 依赖与长连接运维复杂度（连接数、心跳、断线重连）。两者都支持配置灰度发布与命名空间隔离，选型权衡点在：纯 Java 且已用 Nacos 生态 → Nacos；多语言、强治理后台、需要精细灰度规则 → Apollo。

这道题考察对数据库 Schema 版本化管理的工程化理解。核心要回答：① 数据库 Schema 与应用代码一样需要版本化、可追溯、可回滚，手动改表是"运维黑箱"——谁改了什么、何时改的、为什么改全凭口头记忆，环境间不一致是线上事故高发源；② CI/CD 集成迁移把 Schema 变更纳入流水线，与应用代码同节奏发布，实现"代码与 Schema 一起演进、一起审计"；③ 回滚策略的难点在于"代码可回滚但 Schema 难回滚"——删列容易加列难，DROP 后数据不可逆，需用向前兼容迁移而非依赖 schema 回滚；④ 多环境一致性（dev/staging/prod）靠同一套迁移脚本保证，避免"本地能跑线上报错"。理解关键：数据库迁移工具的本质是把 Schema 变更从 DBA 手工操作变成代码化的、可评审、可重放的第一类工程制品。

手动 SQL 脚本阶段：DBA 维护一堆 .sql 文件，靠 Wiki/邮件传递执行顺序，环境间靠"人肉同步"。问题：执行顺序乱、脚本可能被改、无人记录"哪些已执行"，线上经常"少跑一个脚本"导致表结构不一致。

Liquibase（2006）：最早的 Java 生态数据库迁移框架，用 XML/YAML/JSON Changeset 描述变更，跨数据库方言（同一 changeset 可生成不同数据库的 SQL）。核心创新：用 DATABASECHANGELOG 表记录已执行 changeset，支持 preconditions（前置校验）与 rollback 标签（显式回滚）。偏向 DBA/跨库场景。

Flyway（2010）：SQL-first 哲学——迁移脚本就是纯 SQL 文件（V1__init.sql、V2__add_column.sql），用版本号控制顺序，flyway_schema_history 表记录执行历史 + checksum 校验防篡改。简单直观，开发者友好，成为 Spring Boot 默认集成。

Spring Boot 集成（Flyway 默认）：Spring Boot 内置 Flyway auto-configuration，应用启动自动执行迁移，把"数据库准备"与应用启动绑定，实现应用自包含的 Schema 管理。Liquibase 同样可一键集成。

GitOps 式数据库 DevOps：迁移脚本纳入 Git 仓库，PR 评审 Schema 变更，CI 流水线自动执行迁移与测试，把数据库变更从"运维工单"变成"代码评审流程"，与基础设施即代码(IaC)理念统一。

2025 声明式 Schema 管理（Atlas/SchemaHero）：从"指令式迁移"（写 ALTER 语句）演进到"声明式 Schema"——用 HCL/YAML 描述目标 Schema 状态，工具自动 diff 计算迁移 SQL（类似 Terraform 管理 infra）。Atlas 还支持迁移安全检查（检测破坏性 DDL、锁表风险），把"危险迁移"挡在合并前。

1. Flyway 核心：① 版本化 SQL 文件——命名 V{版本号}__{描述}.sql（如 V1__init.sql→V2__add_column.sql），按版本号顺序执行；② checksum 校验——已执行脚本记录 checksum，再次启动比对，脚本被修改则 checksum 不匹配报错（防止偷偷改历史脚本破坏一致性）；③ repair 机制——flyway repair 修正历史表中的 checksum（用于"故意修改已执行脚本"的合法场景，慎用）；④ Baseline——对已有数据库设定基线版本（baselineVersion），只执行基线之后的迁移，避免对存量库全量重跑。Flyway 还有 Repeatable（R__ 前缀，视图/存储过程每次 checksum 变化重跑）和 Undo（仅 Teams 付费版；社区版无自动回滚，生产回滚靠向前兼容迁移与备份而非工具 Undo）。Liquibase 的回滚也仅在 changeset 显式定义 rollback 块时生效（部分 DDL 可自动生成反向 SQL）。

2. Liquibase 核心：① changeset + xml/yaml——用结构化格式描述变更（<createTable>/<addColumn>），可跨数据库生成方言 SQL；② preconditions——执行前校验（如表存在才执行、列不存在才加），增强幂等性；③ rollback 标签——显式定义回滚逻辑（<rollback><dropColumn.../></rollback>），部分操作支持自动回滚（createTable→dropTable）；④ diff 工具——对比两库 Schema 差异并生成 changeset，便于存量库导入。Liquibase 用 DATABASECHANGELOG/DATABASECHANGELOGLOCK 表管理状态。

3. 迁移策略：① 向前兼容迁移（Forward-compatible）：Schema 只做加法（加列、加表、加索引），新代码兼容旧 Schema，回滚代码即可、Schema 不动——生产推荐；② 向后兼容迁移（Backward-compatible）：新 Schema 兼容旧代码（如删列前先停止双写），允许新旧代码共存发布。核心原则：代码可回滚，Schema 尽量不回滚，靠向前兼容设计避免回滚 schema 的灾难。

4. Expand-Contract 模式：处理破坏性变更（删列/改类型）的安全分步法——Expand（加新列/新表，新旧并存）→ Migrate（双写新旧列 + 后台迁数据）→ Switch（读切到新列）→ Contract（确认无读旧列后删旧列）。每步独立发布、可回滚，中间状态任何一步都兼容，实现零停机变更。

5. 零停机迁移：大表 DDL 会锁表（如 MySQL ALTER TABLE 加列在 5.6 前是全表锁）。策略：① MySQL 8.0 Instant DDL（加列/加索引部分支持秒级）；② pt-online-schema-change（pt-osc）/ gh-ost：创建影子表 + 触发器/binlog 同步增量，后台分批拷贝数据，最后 rename 切换，全程不阻塞读写；③ 分批 UPDATE 大表数据避免长事务。

Spring Boot 集成 Flyway 与迁移脚本规范：

# application.yml —— Flyway 配置（Spring Boot 自动装配）
spring:
  flyway:
    enabled: true
    locations: classpath:db/migration          # 迁移脚本目录
    baseline-on-migrate: true                 # 存量库首次迁移自动建基线
    baseline-version: 0                       # 基线版本，0 表示从头执行
    validate-on-migrate: true                 # 启动校验 checksum
    out-of-order: false                       # 禁止乱序执行

-- db/migration/V1__init_schema.sql —— 初始表结构
CREATE TABLE t_order (
    id          BIGINT       PRIMARY KEY AUTO_INCREMENT,
    user_id     BIGINT       NOT NULL,
    amount      DECIMAL(12,2) NOT NULL,
    status      VARCHAR(32)  NOT NULL,
    created_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_order_user ON t_order(user_id);

-- db/migration/V2__add_remark_column.sql —— 向前兼容：只加列，不删改
ALTER TABLE t_order ADD COLUMN remark VARCHAR(255) NULL;  # 允许 NULL，旧代码不写此列不受影响

-- db/migration/V3__expand_contract_step1_expand.sql —— Expand 阶段：加新列
ALTER TABLE t_order ADD COLUMN amount_cents BIGINT NULL;  # 新列存"分"，与 amount 并存

高级开发：① Spring Boot 集成 Flyway/Liquibase 配置——spring.flyway.*/spring.liquibase.* 一键启用，脚本放 src/main/resources/db/migration，应用启动自动迁移；② 迁移脚本编写规范——版本号严格递增（V{yyyyMMddHHmm}__desc.sql 时间戳命名避免多人协作版本冲突），每个脚本只做一件事且幂等，禁止修改已执行脚本（改了 checksum 报错），新需求新增脚本而非改旧的。

架构师决策：

① CI/CD 管道集成迁移：迁移脚本随代码 PR 评审，CI 阶段在临时库执行迁移 + 跑集成测试验证 Schema 正确；部署阶段先执行迁移再发应用（迁移作为独立 Pipeline Step），避免应用启动与迁移并发冲突。生产建议迁移与应用解耦部署——DBA/CI 单独执行迁移，应用启动只校验不迁移（flyway.enabled=false + 预检）。

② 多环境迁移策略（dev/staging/prod）：同一套脚本跨环境，靠 profile 区分配置（如 prod 关闭 clean 防误删）。staging 必须用与 prod 同等量级数据验证迁移性能（大表加索引在 staging 跑通再去 prod）。prod 迁移必须有 rollback plan 与执行窗口。

③ 回滚策略：代码回滚但 Schema 不回滚——靠向前兼容设计保证代码回滚后旧代码仍兼容新 Schema（加列用 NULL/默认值，新代码写新列、旧代码忽略）。破坏性变更（删列）走 Expand-Contract 多版本分步，绝不依赖工具的 rollback 标签回滚生产 Schema（数据不可逆）。真正兜底是备份 + 时间点恢复(PITR)。

④ 大规模表迁移（Online DDL/pt-osc）：千万级大表 DDL 不能用普通 ALTER（锁表风险）。MySQL 8.0 优先用 Instant DDL；不支持的应用 gh-ost/pt-osc 在线改表，配合 --chunk-size 控制拷贝速率。迁移脚本里只写 DDL 语句，实际执行由 DBA 用工具在维护窗口操作，Flyway 记录已执行（flyway repair 同步状态）。

⑤ 迁移审计与合规：flyway_schema_history/DATABASECHANGELOG 表本身就是审计日志（谁、何时、执行了什么 SQL）。金融/合规场景要求所有 Schema 变更可追溯，迁移脚本进 Git + PR 评审 + 执行记录表，满足审计要求。

追问 1：Flyway 的 checksum 失败如何处理？

checksum 失败意味着历史执行记录的脚本内容与当前脚本文件不一致——有人修改了已执行的迁移脚本。这是 Flyway 的一致性保护机制，启动会直接报错阻止应用启动。处理步骤：① 判断是否故意修改——若是合法修改（如修正脚本注释/格式），执行 flyway repair，它会用当前文件 checksum 更新 flyway_schema_history 表，使记录与新文件一致；② 若是误改——应 Git 回退脚本到原始版本（保持 checksum 一致），而非 repair，因为修改已执行脚本可能破坏多环境一致性；③ 生产环境 repair 需审批——repair 会改历史表，必须在 DBA 确认后执行。最佳实践：已执行脚本视为不可变，新需求一律新增版本号脚本，从源头避免 checksum 冲突。

追问 2：零停机添加 NOT NULL 列怎么做？

直接 ALTER TABLE ADD COLUMN col NOT NULL 在多数数据库会因"已有行无默认值"而锁表或失败。零停机分步法（Expand-Contract 思想）：① 第一步加可空列：ALTER TABLE t ADD COLUMN col VARCHAR(32) NULL（不锁表/秒级，旧行 NULL）；② 第二步回填数据：分批 UPDATE 把已有行的 col 填默认值（WHERE col IS NULL LIMIT 1000 循环），避免长事务；③ 第三步加默认值与非空约束：先 ALTER TABLE t MODIFY COLUMN col VARCHAR(32) NOT NULL DEFAULT 'N'（MySQL 8.0 Instant DDL 可秒级，或用 gh-ost）；④ 第四步应用代码改为强制写该列。整个过程每步独立发布可回滚，核心是先加可空列避开 NOT NULL 的全表重写。也可直接用 ADD COLUMN col VARCHAR(32) NOT NULL DEFAULT 'N'（MySQL 8.0 Instant DDL 支持带默认值的 NOT NULL 加列秒级完成），但仍建议分步以兼容低版本与复杂场景。

追问 3：Flyway 和 Liquibase 如何选型？

核心差异在迁移描述方式与目标用户。① Flyway（SQL-first）：迁移就是纯 SQL，开发者写熟悉的 SQL 即可，简单直观、学习成本低、与 DBA 现有 SQL 脚本无缝衔接；缺点是跨数据库需为每种方言写不同脚本，回滚需手写 Undo 脚本（付费版）。适合单一数据库、开发者主导、Spring Boot 项目（Spring Boot 默认集成）。② Liquibase（XML/YAML changeset）：用结构化 changeset 描述变更，自动生成各数据库方言 SQL，跨数据库能力强；支持 preconditions 前置校验、显式 rollback 标签、diff 工具存量导入；缺点是 XML 学习成本高、与纯 SQL 习惯不同。适合需支持多种数据库、DBA 深度参与、有复杂回滚/审计需求的场景（如商业产品交付多客户多种 DB）。选型口诀：单库 + 开发者主导选 Flyway；多库 + DBA 主导选 Liquibase。两者都能满足大部分需求，团队熟悉度是重要决策因素。

这道题考察对两大主流消息中间件的原理级差异与场景化选型：Kafka 以超高吞吐与流式生态见长，RocketMQ（阿里）以金融级可靠、原生事务消息/延迟队列/顺序消息取胜。本质是"吞吐/流处理 vs 业务可靠特性"的取舍。

Kafka：LinkedIn 为日志/埋点高吞吐设计，分区 + 顺序写 + 零拷贝 + 页缓存，天然适配流处理（Kafka Streams/Connect/Flink）。

RocketMQ：阿里开源，Java 实现，NameServer 轻量注册；为电商/金融交易打磨出事务消息、延迟队列、顺序消息、消息回溯等"业务友好"特性。

新变量：Pulsar（存算分离 + 分层存储）在云原生场景崛起，形成 Kafka/RocketMQ/Pulsar 三足鼎立。

RocketMQ 5.x（2022，云原生化）：引入Proxy 无状态代理与gRPC 客户端协议（RIP-39），将客户端与 Broker 解耦——5.x 客户端不再持有路由、直连 Proxy 由其转发（Local 模式可同进程运行以兼容 4.x）。客户端 SDK 分两支：Remoting SDK（rocketmq-client，4.x/5.x 通用，Java 为主）与 gRPC SDK（rocketmq-client-java 等，仅 5.0+，多语言），二者 API 不兼容需改代码迁移。事务消息/延迟队列/顺序消息在 4.x、5.x 均支持，5.x 通过新 gRPC API 暴露；生产落地需先升服务端到 5.0 再替换 SDK。

RocketMQ 事务消息原理：① 发 Half（预备）消息，对消费者不可见；② 执行本地事务；③ 根据结果 Commit/Rollback；④ 若状态未知，Broker 定时回查生产者确认最终状态。从而把"本地 DB 事务"与"消息发送"对齐为最终一致。

// RocketMQ 事务消息：Half → 本地事务 → Commit/Rollback → 回查
TransactionMQProducer p = new TransactionMQProducer("tx_group");
p.setTransactionListener(new TransactionListener() {
    public LocalTransactionState executeLocalTransaction(msg, arg) {
        return orderService.create(arg) ? COMMIT : ROLLBACK; // 本地事务结果
    }
    public LocalTransactionState checkLocalTransaction(msg) {
        return orderService.exists(msg) ? COMMIT : UNKNOW; // 回查
    }
});

延迟队列：RocketMQ 用 setDelayTimeLevel(3) 支持固定档位（如 10s/30s/1m…，共 18 级）；5.x 新 gRPC API 额外支持任意精度 timing message，4.x 自定义任意时间需外挂 timing wheel 或改 level 配置；Kafka 无原生延迟，常用"独立延迟 topic + 时间轮"或外部调度实现。

顺序消息：RocketMQ 用 MessageQueueSelector 按业务 key（如订单号）路由到同一队列，保证队列内严格有序。

幂等消费：无论是 Kafka 的 at-least-once 还是 RocketMQ 重投，消费端必须按业务唯一键做幂等（去重表/版本号）。

追问 1：Kafka 为什么不适合做强事务消息？ Kafka 的 exactly-once 是"读-处理-写"的有限 EOS，没有 RocketMQ 的 Half+回查机制，难以把"外部 DB 事务"与"消息"对齐为最终一致。

追问 2：RocketMQ 回查机制为何必要？ 本地事务执行后生产者宕机，Broker 不知道 Commit/Rollback，必须回查生产者恢复最终状态，否则消息永久半消息或误决。

追问 3：为什么阿里系偏爱 RocketMQ？ 阿里系（淘宝/支付宝）大量使用，事务消息/顺序消息/延迟队列是电商交易核心能力，考察候选人对业务可靠消息的实战理解。

选型结论：高吞吐/流处理选 Kafka（顺序写 + 零拷贝 + 页缓存是吞吐关键），金融级事务/延迟队列/顺序消息选 RocketMQ；削峰靠 MQ 缓冲下游压力。

在掌握 Kafka vs RocketMQ 选型基础上，补齐三个业务落地高频细节：削峰填谷的落地策略、RocketMQ 死信 / 重试机制、消息轨迹。

• 削峰填谷落地策略：① 消费者限流——用令牌桶控制消费速率，让消息在 Broker 端积压缓冲，下游按自身能力消费，避免瞬时洪峰打垮下游；② 队列堆积告警 + 弹性扩容——监控消费 lag（如 RocketMQ 控制台 lag、Kafka consumer lag），超过阈值触发告警并自动扩容消费者实例（K8s HPA 按 lag 扩缩容）；③ 分级降级——核心消息进高优队列优先消费（RocketMQ 多 Topic 分级 / 队列优先级），非核心消息延迟消费或降级丢弃，优先保障核心链路。
• RocketMQ 死信队列（DLQ）：命名规则 %DLQ%ConsumerGroupName（如 %DLQ%order_consumer_group），消息重试 16 次仍失败后自动转入该 Topic。DLQ 中的消息不会自动消费，需人工介入排查或定时任务扫描补偿。与 Kafka 对比：Kafka 没有内置 DLQ，需业务自行实现（消费失败写 error topic + 定时重放），这是 RocketMQ 在业务可靠性场景的明显优势。
• 重试机制：RocketMQ 重试间隔按延迟 level 递增（1s, 5s, 10s, 30s, 1m, 2m, 3m, 4m, 5m, 6m, 7m, 8m, 9m, 10m, 20m, 30m, 1h, 2h，共 18 档）；重试消息存储在 %RETRY%ConsumerGroupName 私有 Topic 中。消费者处理返回 RECONSUME_LATER 触发下次重试，返回 CONSUME_SUCCESS 表示消费成功。
• 消息轨迹（Message Trace）：开启 traceTopic=RMQ_SYS_TRACE_TOPIC 后，每条消息的生产-消费全链路被记录：发送时间、存储 Broker、消费时间、消费状态、消费耗时等。用途：排查消息丢失（生产未发出 / 消费未收到）、重复消费（同一消息多次消费记录）、消费延迟（消费耗时异常）三大问题，是生产排障的核心抓手。

这道题考察对 eBPF 无侵入可观测能力 的理解，以及它和传统 APM Agent / OpenTelemetry 埋点 的边界分工：eBPF 在内核态挂载钩子，不改应用代码、不注入 Agent 即可采集网络、系统调用、文件 IO、函数延迟等底层信号，是 2025-26 云原生可观测的新范式。

内核模块（危险）：直接改内核，崩溃风险高、需重编内核。

cBPF → eBPF：eBPF 引入校验器（verifier），保证程序安全（不会死循环/越界）后才注入内核，无需改内核源码或重启。

CO-RE 与生态：BTF + CO-RE 实现"一次编译到处运行"；生态涌现 bcc/BCC、Cilium/Hubble、Pixie（自动抓请求/SQL）、Parca（持续 Profiling）、OpenTelemetry eBPF 导出器。

机制：eBPF 程序挂载到内核钩子（kprobe/uprobe/tracepoint/XDP/TC），运行时由校验器确保内存安全，通过 perf buffer/ring buffer 把数据送用户态。可观测 TCP 重传、syscall 延迟、调度延迟、文件 IO。

典型场景：① K8s 网络排查（Cilium + Hubble 看服务间流量、重传、丢包）；② 数据库慢查询根因（eBPF 抓 syscall/IO 延迟，定位是网络还是磁盘）；③ 无侵入 APM（Pixie 自动捕获请求与 SQL，无需埋点）；④ 持续 Profiling（Parca/Pixie 抓 CPU 火焰图）。

落地建议：优先用成熟工具（Cilium/Pixie/bcc）而非自写 eBPF；OTel 可对接 eBPF exporter 统一可观测底座。

局限：内核/BTF 前提——基础 eBPF（kprobe/tracepoint）需 4.9+ 稳定；CO-RE 需内核启用 BTF（5.1+，或发行版随镜像提供 BTF 转储），否则需按内核版本重编译；业务语义（如完整 SQL 文本、用户态对象）仍需 Agent/uprobe 配合；编写调优门槛高。

追问 1：eBPF 能完全替代 APM Agent 吗？ 不能。eBPF 在内核态拿不到上层业务语义（如 Spring 方法入参、完整 SQL 文本），这类需用户态 Agent 或 uprobe 解析；二者应协同。

追问 2：eBPF 相比 Sidecar 开销如何？ eBPF 在内核态，无 Sidecar 的额外网络跳数与资源占用，对延迟敏感应用更友好；但覆盖范围（如七层协议解析）不如 Sidecar 灵活。

追问 3：安全边界是什么？ 校验器强制内存安全、禁止越界/死循环/非法绑定；权限随内核演进收敛——旧内核需完整 CAP_SYS_ADMIN，5.8+ 引入细粒度 CAP_BPF 即可，无需再授 CAP_SYS_ADMIN；绝不能加载未经验证器校验的 eBPF 程序。

FinOps 的本质不是"砍预算、压价"，而是把云成本变成"可测量、可归因、可持续优化"的工程问题。它考察你是否具备成本意识、能否用量化闭环把"事后看账单"升级为"事前预算 + 事中治理 + 事后复盘"。FinOps Foundation 提出的三大支柱：Inform（看见谁花了多少）→ Optimize（右尺寸/选型优化）→ Operate（预算·告警·责任到人）。成本公式只有一行：

成本 = f(用量 × 单价)。降本只有两条路：减用量（右尺寸/缩容/清理闲置/数据冷化）或降单价（预留/Spot/包年/区域价差）。评判标准用单位成本 / 成本效率（每万请求成本、每 GB 存储成本、CU 利用率率）而非绝对金额——因为业务在增长，绝对额上升未必是浪费。

自建机房是重资产前置成本（买了就要用，容量定了就固定）；上云是按需弹性，省了前期资本却把成本转移到了"每一毫秒的波动"上。云的成本失控根源在两点：① 弹性=双刃剑——按需扩容很方便，代价是"没人为单笔开销负责、闲置资源无限堆积"；② 账单归属不清——费用下沉到了 K8s Pod 级别，没有人/团队对这个数字负责。

因此 2020 前后 FinOps 从"省钱运动"演化为"工程+财务+业务的协作文化"（FinOps Foundation 与云厂商共建）：用 Framework 三相 Inform / Optimize / Operate 把成本变成共享工程指标。实践中通常与"云账单治理、云成本分析（AWS Cost Explorer / FinOps Hub）、K8s 成本规控（Kubecost / OpenCost）"结合落地。

成本三高：计算（占比最大）> 存储（低频膨胀）> 网络（流量黑洞）。K8s 场景下成本按 request/limit 与 Pod 归属分摊到 Namespace/团队。（注意：预留/Spot 折扣、跨 AZ 流量计费、账单粒度等具体机制高度依赖云厂商，本卡给出通用方法论，落地须对照目标平台计费文档与 API。）

六步闭环是落地主线：定义单位成本 → 成本归因（Tag/Label）→ 预算与预测 → 优化动作（右尺寸/Spot/预留/冷化）→ 效果度量 → 责任到人。每条都遵守"先看得见，再省得下"——没有归因就谈不上治理。

1. 成本可见与归因：全链路约定 Tag/Label（环境/项目/业务线/owner），云账单按 Tag 分摊到团队；定期生成"成本报告 + 周趋势"。K8s 用 OpenCost 按 Namespace 归因。

2. 右尺寸与弹性：依据 CPU/RAM/流量监控指标对资源"降配"而非只"升配"；用 HPA + KEDA 让伸缩只按需放大，空闲时段自动缩容。

3. 计算降单价：基线稳定负载用预留/承诺用量（包年包月成本腰斩），波动负载用按量，可将中断、无状态、可重入的批处理跑在 Spot/竞价实例；GPU 按"分时共享"拆给多个租户摊薄单价。

4. 存储与数据成本：数据冷热分层——对象存储生命周期规则滚到低频/归档；TTL 清理日志、临时表、中间结果；镜像瘦身、标签去重防镜像长尾。

5. 网络成本：CDN 分流热点、聚合跨境/跨 AZ 带宽、避免"免费期内最大、出站流量秒级爆表"的 EIP 泄漏。

6. 运营闭环：成本预算 + 阈值告警（如预超预算 80% 即告警）；非生产环境"下班停机/按需冷启动"；月度"成本回顾"按 owner 出红黑榜。

# K8s 降本：为 Pod 设置贴近真实用量的 request，并启用 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef: { kind: Deployment, name: web, apiVersion: apps/v1 }
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: queued_jobs
        target:
          type: AverageValue
          averageValue: 10

追问 1：怎么让研发"主动"降本而不是靠行政命令？ 核心是责任共担 + 反馈闭环：把成本按 Tag 分到每个团队"每天可见"（Inform），把"单位成本趋势 / 成本红黑榜"作为团队显性指标而非指令；配合"预算透明 + 超预算前先说明"的文化，避免一刀切砍功能。可落地的抓手：成本归属到负责人 + 超支预警给到 owner。

追问 2：预留 / 按量 / Spot 怎么配比？ 基线稳定负载用预留（包年省钱），弹性波动用按量，可中断批量用 Spot。典型配比如核心应用 60% 预留 + 30% 按量 + 10% Spot，跑批任务可到 80% Spot；配比随业务峰谷与容错能力动态调整，预留必须贴近基线、宁少勿多。

追问 3：怎么证明我们真的"省了钱"？ 不能只看总账单（业务量在涨），要用单位成本指标——每万请求成本、每用户月成本、CPU 利用率天花板；在同等业务量口径下做同比/环比，才能区分"真正的浪费"与"业务增长导致的合理上升"。

考察的是"单机定时任务 → 分布式调度"的架构演进认知：能否说清 Quartz 单机与集群的局限、XXL-Job 与 Elastic-Job 为解决"任务不重、不空跑、可水平扩展"分别走了哪条路线。头部大厂的调度器普遍已从自建轮子走向 XXL-Job / Elastic-Job / 云厂商（阿里 SchedulerX、腾讯）。选型不是"谁更牛"，而是匹配任务规模、分片需求、运维成本、社区与公司既有技术栈；调度四大问题、分片/故障转移原理与完整选型矩阵见 C11.13（两卡互补，不重复展开）。

JDK Timer(1996)：单线程、按固定速率/延迟、单任务阻塞会影响其他任务、任务抛异常即中断，只适合极简单场景。

JDK ScheduledThreadPoolExecutor(CU)：线程池 + DelayedWorkQueue 最小堆，多线程并行、异常隔离于各任务，仍是单机的进程内调度，挂在哪个节点就只在哪个节点跑。

Quartz(单机→集群)：先以 DB 存储 JobDetail/Trigger（RAMJobStore→JobStoreTX），QRTZ 三表做分布式独占锁；集群解决"多实例跑同任务需互斥"，但痛点明显——基于 DB 行锁抢独占，性能差、不支持分片。

XXL-Job(2016)：调度中心 Admin + 执行器 Executor 分离，调度中心统一触发，执行器通过 RPC 回调注册 + 按 IP 分片广播；支持动态扩缩执行器、失败重试、报警，运维简单，是中小团队最常用。

Elastic-Job(当当)：社区并入 Apache 后改名 ShardingSphere-ElasticJob，基于 ZooKeeper 协调，(2,1) 模式主从选主 + 任务分片，天然面向数据分片任务，适合大数据搬运/ETL，比 XXL-Job 更控制面重但分片语义更内建。

分布式调度要解决的三个公理：不重（同一分片同时只被一个执行器跑）、不丢（漏跑要有补偿与重试通道）、可扩（任务随业务量水平扩展，而非困在单节点）。所有框架的差异本质是协调者去哪：Quartz 用 DB 锁（弱一致、易成单点），XXL-Job 用集中式调度中心 + 心跳 + 路由策略，Elastic-Job 用ZooKeeper 临时节点选主 + 一致性分片。选型即选择"协调基础设施与任务形态的匹配度"。

轻量单机/秒级：优先 @Scheduled + 分布式锁（悲观锁/Redis SETNX）兜底，避免引入框架。

中小规模（几十~几百任务）：XXL-Job 开箱即用，CRON + 失败重试 + 报警 + 控制台可视化，成本最低。

数据分片/ETL/大数据：Elastic-Job 的 Sharding 让 N 台执行器按分片挂载数据，如 分片项 % 执行器数 分片路由，天然适配"百万行批量搬运"。

粒度与高可用：调度中心建议部署多实例 + DB 高可用；执行器按任务重要性决定是否多机房冗余；所有框架都会存在"时钟不一致/执行慢于 CRON 周期"需要幂等兜底。

追问一：XXL-Job 的"分片广播"与"轮询/一致性哈希"路由策略区别？——分片广播是执行器各自领一个分片并行处理；轮询/哈希是调度中心把触发请求派给某个执行器执行。

追问二：为什么 XXL-Job 不用 ZK 而 Elastic-Job 用 ZK？——XXL-Job 强调"轻量 + 明确的任务管理心智"，用 DB + 内存即可；Elastic-Job 从分片一致性出发，ZK 的临时节点天然表达"执行器存活与选主"。

追问三：调度中心挂了一种可能漏任务，如何兜底？——多实例 + 健康检查 + 失败告警 + 幂等；对关键链路提供补跑入口（手动/补偿任务）。

• 低估 Quartz 集群的 DB 锁瓶颈：QRTZ 行锁在高频任务下成为热点，集群越大性能越差。
• 任务执行时间 > CRON 周期：不加并发控制会导致上一轮没跑完下一轮已触发，需阻塞/单实例 <= 1 保护。
• 执行器水平扩容但任务没有分片：多执行器只带来冗余，不带来吞吐，除非任务可拆。
• 用 CRON 调度"非常规步长"：如"每 90 秒"，CRON 不好表达，应改用固定延时（initialDelay+fixedDelay）。

考察对延时任务"数据结构与调度驱动"的底层理解：时间轮不是新的调度算法，而是把"到期判定"从 O(n) 遍历优化成O(1) 指针拨动 + 桶内按轮数分级。常见定时/延时任务实现只有三类驱动：轮询扫描（DelayQueue 最小堆）、刻度拨盘（时间轮）、外部原子队列+轮询（Redis ZSET）。本质上要回答"到期事件如何被以最低成本发现"。

DelayQueue / ScheduledThreadPoolExecutor：用二叉最小堆保证堆顶即最近到期，取出线程 take() 阻塞到点；O(log n) 插入删除，实现简单，是 JUC 标准方案。

时间轮 HashedWheelTimer（Netty）：一个环形数组（tick）按固定 tickDuration 拨动，每 tick 处理当前槽内的任务链表；为解决长延时，给任务带 remainingRounds 轮数，几圈后再取出执行。插入 O(1)，到达时仅触发当前槽，避免全局扫描，吞吐远高于最小堆，但存在"到点误差 ≤ tickDuration + 并发槽处理延迟"。

Redis 实现延时队列：ZSET（score=到期时间戳）+ 轮询 zrangebyscore 取到期任务 + 预取补偿；跨节点共享、可持久化，是分布式延时任务的通行方案（Redisson DelayedQueue 底层即 ZSET + 发布订阅）。

延时任务本质是"事件队列 + 时间索引"，复杂度来自"到期判断"：最小堆以额外 log 代价换取任意精确到期；时间轮以固定抗震（tick 粒度）换取 O(1) 批处理吞吐；Redis 把队列搬到共享存储换取分布式一致性。工程取舍铁律：同机大量任务、毫秒级抖动可容忍 → 时间轮；全局有序小任务 → 最小堆；跨实例/宕机可恢复 → Redis/消息队列延时消息。

秒杀/订单超时关闭通常三种落法：Redis ZSET + 定时扫描（简单，吞吐足够）、消息队列延时消息（RocketMQ 延时等级 / RabbitMQ TTL+DLX），以及时间轮 + 本地优先（要求高吞吐的网关/连接中超时，如 Netty IdleState 检测底层即时间轮）。

经验：业务"超过 24h 未支付自动关闭"这类分钟级宽松延时，不需要精确到毫秒，用 Redis 轮询即可；"毫秒级会话超时/废防止重连"才需要时间轮的高吞吐。

追问一：时间轮为什么会有微小的误差？——处理器被慢 tick 的溢出槽阻塞，或槽内任务过多导致单 tick 处理超时，出现 sheak 误差；对精确到点敏感的任务要放大 tick 或改用最小堆。

追问二：时间轮如何实现"超长延时"？——remainingRounds 分级，每次到槽只减 1 轮，等于把巨大刻度摊到多圈，空间与 O(1) 保持。

追问三：Redisson DelayedQueue 的实现？——Redis ZSET 按 score 排序 + 客户端 poll(millis) 拉取到期元素 + 发布订阅通知抢占者，配合空值预取。

• tickDuration 设得太粗/太细：太细空转浪费 CPU，太粗放大到期误差；要按业务精度定刻度。
• 单槽任务积压拖垮所有 tick：同槽任务链表极长会让后续任务集体延迟，需关注热点桶分布。
• Redis ZSET 轮询粒度不当：轮询太频繁压力大，太稀疏会晚触发；用 pop/mv 竞争 + 通知 减少空转。
• 把"延时任务"当"定时任务"用：CRON 固定周期用定时器，一次性到期用延时队列，别混用。

• 时钟回拨：依赖本地时钟的延时任务在 NTP 回拨时可能早触发/晚触发；分布式场景优先用 Redis/MQ 服务端时间或单调业务截止时间戳，并对回拨做检测（拒绝过大负跳）。
• 动态分片：海量延时任务按 shard = hash(bizId) % N 分槽扫描，执行器增减时重算分片并做窗口补偿，避免漏关单。
• 订单超时关单：分钟级宽松延时用 Redis ZSET/延时消息即可；关单必须幂等（状态机：待支付→已关闭），并与库存回补、优惠券回滚同事务或本地消息表，详见场景题互链。

事件的本质：分布式环境下任何"定时触发"都不能依赖单点先验，唯一性必须落到任务执行侧的幂等与锁。所谓"不重"靠分布式锁 / 唯一约束 / 幂等表；"不漏"靠分片 + 故障转移 + 补跑。它考察的是把"单机 for 循环"升级为"可横向扩展、可在任意节点失败恢复"的系统能力，而非某框架的 API。

单机：只跑一个实例即可，天然不重不漏，但单点故障即停摆。

高可用（主备）：主动/被动互斥——靠 DB 唯一键或 SELECT ... FOR UPDATE / Redis SETNX 抢"锁记录"，抢到的实例执行，另一台不执行；解决了不重，但机器故障期间任务空窗。

分布式调度：XXL-Job/Elastic-Job 把这些能力内建为"调度中心统一触发 + 执行器抢执行/分片 + 心跳失联重派"。故障转移 = 执行器超时未回报，调度中心把该分片重新派给存活执行器。

多机房 / 云原生：任务提高可用性可跨机房冗余，但一致性风险上升，通常结合"单机房执行 + 异地只读"或"业务侧幂等表"收敛。

分布式一致性的根本约束是CAP 无法兼得：调度触发属于"写"，跨机房保证不重放弃强一致、用最终一致 + 幂等补偿。落点的公理只有一条：触发可以重复，处理必须幂等。因此"不重"不是靠调度器保证，而是靠业务侧对同一业务主键的唯一处理（幂等表 / 分布式锁 / 数据库唯一索引）收敛重复触发。

幂等三件套：① 唯一业务键（如 orderId）建唯一索引，重复插入被拒；② 幂等表/消息去重（插入先查已处理）；③ 分布式锁（Redis SETNX + 过期时间，或 ZK 临时节点）包裹任务主体。

动态分片：把数据按 id % 分片数 或主键范围路由，执行器增减时分片重算并触发一次重分布；用"轮询/一致性哈希"减少迁移量。

故障转移与补跑：执行器心跳超时 → 调度中心重派；同时提供补跑入口（手动触发某分片/某天任务）。对关键任务设置失败重试上限 + 告警。

追问一：分布式锁实现不重的边界？——锁需要原子 + 过期时间（防死锁），但过期时间可能未执行完就过期导致重复，需用"续期 + 业务幂等"双保险。

追问二：分片数变更时老数据会不会漏跑？——分片重算后需对"已分片但未完成任务"做一次补偿扫描，否则切换窗口漏数据。

追问三：多机房主备还是双活？——金融场景常用"主机房执行 + 备机房待命，主挂自动切换并补跑窗口任务"，同时用幂等表防切换覆盖。

• 只防不重不防不丢：调度器重复触发被幂等挡住，但故障空窗漏掉的任务没人补，必须设计补跑。
• 锁过期时间拍脑袋：设太短导致未执行完锁已失效、重复执行；设太长阻塞新的故障切换。
• 分片与数据分布耦合：数据倾斜是分片常态，按主键哈希相对均衡，按日期/区域可能热点。
• 把"幂等"当成"去重即等于幂等"：去重只能拦重复触发，业务状态还需"重复触发时结果一致"才是真幂等。

上线门禁：① 业务主键唯一约束或幂等表已建；② 调度任务有分片清单与补跑入口；③ 执行超时/心跳阈值与锁续期写进 Runbook；④ 多机房场景明确「谁执行、谁待命、切换窗口补跑」。

可观测：任务维度指标（触发次数、成功/失败、耗时 P99、重派次数、补跑次数）；告警绑定责任人。复盘区分「重复触发被幂等挡住」与「空窗漏跑」。

容量：分片数与执行器数、下游连接池同一模型；倾斜分片单独限流。定时任务常是对账/补偿载体，失败必须可审计（对齐 G06.03）。

Kafka Streams 是嵌入式流处理库（跑在应用 JVM 内），不是独立集群。核心抽象是Stream-Table Duality：事件流（KStream）与物化视图（KTable）可互相转换；有状态计算靠本地状态存储 + changelog topic实现故障恢复。与 C11.11（Broker 侧 EOS）、C11.18（仅点名流生态）互补——本题回答「在 Kafka 上如何做应用级有状态处理」。

0.10（2016）：引入 Streams DSL，把消费-处理-生产做成库，免独立作业集群。

0.11+：对接幂等生产者与事务，支持 processing.guarantee=exactly_once_v2（读-处理-写原子）。

Interactive Queries：状态可被本机/远程查询，把「流处理结果」变成可服务的物化视图。

与 Flink 分道：Streams 绑定 Kafka 生态、运维轻；Flink 做跨源/复杂窗口/CEP（场景落地见 S11.03）。

拓扑：Source → Processor → Sink 构成 DAG；DSL（filter/map/groupByKey/aggregate/join）编译为 Processor Topology，按 task = 分区子集并行。

状态存储：Keyed 状态默认 RocksDB 本地盘；每次更新写changelog topic。实例故障后从 changelog 重放恢复，Standby Replica 可缩短恢复时间。

EOS：消费位移 + 状态 changelog + 产出 topic 纳入同一事务（依赖 Broker 事务协调器，原理见 C11.11）。语义边界是「Kafka 内读-处理-写」，外接 DB 仍需业务幂等。

// Streams DSL：按 userId 聚合近 1h 点击次数（简化）
StreamsBuilder b = new StreamsBuilder();
b.stream("clicks", Consumed.with(Serdes.String(), clickSerde))
  .groupByKey()
  .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofHours(1)))
  .count(Materialized.as("click-store"))
  .toStream()
  .to("click-1h");
Properties props = new Properties();
props.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, StreamsConfig.EXACTLY_ONCE_V2);
new KafkaStreams(b.build(), props).start();

容量：并行度 ≤ 输入 topic 分区数；状态盘 IOPS 与 changelog 吞吐要预留。开启 Standby 换恢复时间。

运维：关注 rebalance、状态恢复耗时、任务迁移；changelog 保留策略与状态大小绑定，勿随意缩 retention。

追问 1：为何 EOS 仍要业务幂等？ 事务保证 Kafka 内原子，下游 HTTP/DB、重复部署窗口、手动重置 offset 仍可能重复，业务唯一键不可省。

追问 2：rebalance 风暴怎么治？ 静态成员（group.instance.id）、合理 session.timeout、减少不必要重启；大状态优先 Standby + 调大 rebalance 超时。

追问 3：Interactive Queries 的一致性？ 查询本地状态是异步最终一致；跨实例需 metadata 路由到 owning task，故障切换期可能短暂不可查。

• 把 Streams 当独立集群：无 JM，扩缩靠应用副本；副本数与分区/任务分配需一起设计。
• 忽略 changelog 成本：大状态 = 大 changelog 流量与恢复时间，磁盘与 Kafka 容量要算进容量规划。
• 用 Streams 硬做跨 DB 事务：库外副作用不在 EOS 边界内，应改 Flink 两阶段提交 Sink 或业务幂等表。
• 与 C11.11 混淆：Broker EOS ≠ Streams 应用拓扑；前者是消息语义底座，后者是处理层编排。

上线门禁：① processing.guarantee 与 Broker 事务版本对齐（exactly_once_v2）；② changelog / 输出 topic 保留策略与状态大小同模型；③ Standby 副本与 rebalance 超时写进容量计划；④ Interactive Queries 故障切换窗口有业务兜底。

与 Flink 对照（运维面）：Streams 无 JM/TM，扩缩=应用副本；Flink 要管 Checkpoint 存储、托管内存、反压链路。Kafka→Kafka 轻聚合优先 Streams；跨源/CEP/大状态/Savepoint 蓝绿优先 Flink（C11.25）。

可观测：task 迁移次数、状态恢复耗时、changelog 吞吐、消费 lag；告警区分「rebalance 风暴」与「状态盘打满」。

Flink 把事件时间 + 分布式状态 + 一致性快照做成一等公民：用 Checkpoint 在失败时恢复「算子状态与输入位置」的一致切面，用 Watermark 推进事件时间窗口。本题讲引擎与运维契约；CEP/风控场景编排见 S11.03，Kafka 内轻量流处理见 C11.24，Broker EOS 底座见 C11.11。

批处理时代：MapReduce/Spark 以微批近似实时，延迟与状态语义弱。

Flink 流优先：真正记录级流，Chandy-Lamport 风格分布式快照（Barrier）实现 Exactly-Once 状态恢复。

流批一体：同一 DataStream/Table API 覆盖实时与回溯；湖仓 Sink（Iceberg/Hudi）成为标配。

运维成熟度：Unaligned Checkpoint、增量 RocksDB Checkpoint、弹性扩缩与自动调参进入生产主流。

Checkpoint：JobManager 注入 Barrier，对齐后各算子把状态快照到 State Backend，Source 记录偏移。恢复时从最近成功 Checkpoint 重启，状态与输入位置一致。

端到端 EOS：状态 EOS + Sink 两阶段提交（如 KafkaTransactionalSink）→ 外部系统也「只提交一次」。Sink 不支持事务时退化为至少一次 + 幂等写。

Watermark：表示「小于该时间戳的事件基本到齐」，驱动事件时间窗口关闭。乱序用 allowedLateness / side output；空闲源需 idle 标记，否则 Watermark 不推进、窗口永不关。

// 事件时间窗口 + Watermark（示意）
DataStream<Event> s = env.fromSource(kafkaSource, WatermarkStrategy
    .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
    .withTimestampAssigner((e, ts) -> e.getEventTime()), "src");
s.keyBy(Event::getUserId)
  .window(TumblingEventTimeWindows.of(Time.minutes(1)))
  .aggregate(new CountAgg())
  .sinkTo(kafkaSink);  // 事务 Sink 拿端到端 EOS
env.enableCheckpointing(60000);
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000);

背压：Web UI 看算子忙闲与缓冲；常见瓶颈是同步外部 IO、过重序列化、数据倾斜。对策：Async I/O、再平衡 key、提并行度、本地聚合后再外发。

状态治理：TTL 清理过期 Keyed State；大状态作业预留恢复窗口；Savepoint 进发布流水线（蓝绿切作业）。

追问 1：Aligned vs Unaligned Checkpoint？ Aligned 等 Barrier 对齐，反压时易卡住；Unaligned 可带着未处理缓冲一起快照，缩短反压下 CP 时间，但快照更大，需权衡。

追问 2：Checkpoint 成功是否等于端到端不丢不重？ 否——还取决于 Sink 是否参与两阶段提交；否则状态精确恢复 + 外部至少一次，要靠幂等收敛。

追问 3：与 S11.03 如何分工？ 本题是引擎契约（CP/WM/状态/背压）；S11.03 是「Kafka + Flink CEP + 规则热更新」风控场景拼装，两者交叉引用、不重复展开 CEP DSL。

• 处理时间冒充事件时间：乱序与回溯重放会算错窗口，生产尽量事件时间 + Watermark。
• Watermark 不推进：某并行度空闲未标 idle、或时间戳解析错误，窗口永久挂起。
• Checkpoint 超时只调大间隔：根因常是反压/外部 IO；先消瓶颈，再改 timeout/minPause。
• 状态无限增长：无 TTL、窗口状态未清理，RocksDB 与 Checkpoint 存储被打满。
• 把 Kafka 事务当成 Flink 状态 EOS：Broker 侧 EOS（C11.11）只保证消息路径；Flink 还要 Checkpoint 对齐与 Sink 两阶段提交才谈端到端。

上线门禁：① Checkpoint 间隔/超时/minPause 与反压演练通过；② State Backend=RocksDB + 增量 CP；③ Kafka Source 与事务 Sink 版本矩阵写清；④ Savepoint 进发布流水线（升级/改并行度必走）。

Kafka 对接清单：分区并行度 ≤ 源分区；消费组与 Flink 作业 UID 稳定；EOS 时事务超时 > Checkpoint 间隔；Schema 演进走 Registry（呼应 C11.11 扩展）。

可观测：checkpoint duration/size、numLateRecords、反压比例、Kafka lag、RocksDB 内存与本地盘；失败恢复 RTO 写进 SLO。

官方主线：Apache Flink Docs — Stateful Stream Processing / Checkpointing / Watermarks / Kafka SQL Connector。Barrier 对齐与 Unaligned Checkpoint、Savepoint vs Checkpoint 以官方语义为准。

与速查交叉：选型一句见 E08.04；Kafka 内嵌处理见 C11.24；CEP 风控拼装见 S11.03。

积压不是「多加几个消费者」一句话：先分型（流量突增 / 消费变慢 / 毒消息卡住 / 位点错误）。

积压速率 = 生产速率 − 消费速率；单分区热点会使扩消费者无效。毒消息无限重试会打爆下游。位点重置是数据决策，不是默认止血。

分级：

1. L1 看积压速率与消费 RT。
2. L2 是否单分区/单队列热点。
3. L3 是否反复失败同一批消息。
4. L4 业务是否允许丢弃/延迟。

动作顺序：扩消费者 → 限速生产 → 毒消息进死信 → 必要时只读降级。

参数：并发消费者、拉取批量、消费超时、最大重试、死信 Topic、位点重置权限（双人）。看板：积压量、消费成功率、死信速率。

失败模式：盲目 reset 位点丢数据；无限重试打爆下游；扩容后单分区仍串行。回滚点：恢复原并发与订阅组配置。

积压分级：下游故障→暂停消费；消费慢→扩容/提并发；毒消息→跳过/死信；流量洪峰→限产。禁止无证据盲目丢弃。

每级都要有可回放位点与对账任务；扩容前确认分区与消费组模型。

量化判定：积压速率 > 消费速率 × 1.5 且持续 5 分钟为 L1；单分区积压占比 > 60% 说明热点，扩消费者无效，应先重设分区键再均衡；死信率 > 0.1% 触发人工介入。演进：把「积压量、消费 RT P99、死信速率、位点滞后」四指标做成一张分级告警看板；位点重置权限收归双人复核，且重置前必须确认下游幂等能力。

本地消息表解决「本地事务与发消息」一致性，不是银弹。按清单落地：表结构、扫描、重试、对账、清理。

同库事务写业务行 + 消息行，再用异步发送；消费侧幂等；对账补齐最终一致。跨库本地消息表无法提供原子性。

清单：

1. 同库事务写业务+消息行。
2. 状态机 NEW/SENT/DONE/DEAD。
3. 定时扫描发送 + 退避重试。
4. 消费幂等键。
5. 对账任务。
6. 归档清理。

上线前演练：发送失败重试、重复投递。

字段建议：biz_key、payload、status、retry_cnt、next_time、updated_at。扫描间隔与批量可配；DEAD 告警可行动。关联 G06.03。

失败模式：消息表与业务不同库；无幂等导致重复扣款；扫描无退避打爆 MQ。回滚点：暂停扫描器，保留表数据人工补发。

本地消息表最小闭环：同事务写业务+outbox → 异步投递 → 成功标记 → 对账补偿。缺对账等于假可靠。

落地清单：表结构、投递线程、重试退避、死信、对账窗口与告警。

量化：扫描间隔 5~30s（按 RT 敏感度取），单批 ≤ 500 行，重试退避 1s → 5s → 30s → 5min，最大重试 8 次后转 DEAD。对账窗口 = T+1 全量 + 每 10 分钟增量，差异率 > 0.01% 告警。演进：outbox 表按 biz_key 哈希分表，单表超 5000 万行或扫描耗时 > 1s 即分片；量级再上一个台阶可退化为事务消息 / CDC 订阅，但必须保留对账兜底。

死信不是垃圾桶：要有分类、重放策略与审计。延迟消息常见坑是「到期瞬间洪峰」。

死信应保留失败原因码与原始位点信息；重放必须限速且可审计。延迟到期要按曲线削峰，避免当成普通高峰硬扛。

值班顺序：

1. 死信速率与原因码。
2. 抽样 payload。
3. 可修则修后限速重放。
4. 不可修则人工工单。
5. 延迟队列看到期曲线，必要时削峰。

开关：死信重放速率、最大重放次数、延迟级别表、到期告警阈值。禁止无审计的生产控制台重放。

失败模式：死信无限回流原 Topic；延迟到期打满下游；重放打乱顺序且无幂等。回滚点：停止重放任务，恢复原消费组。

死信堆积先分型：业务拒绝 vs 系统故障。重放要控速并保证幂等；顺序主题重放勿打乱分区键。

延迟消息值班：看到期堆积与消费滞后；止血可暂停调度或降级即时路径。

量化：死信重放速率 ≤ 生产均值 × 0.3（防止重放把下游再打挂），最大重放 5 次；延迟消息按到期曲线分桶（±1min / ±5min / ±30min）削峰，避免整点洪峰。演进：每条死信补 reason_code + 原始位点 + 首次失败时间，重放走审计流水（谁、何时、多少条）；顺序主题的重放必须按分区键串行，且整批幂等。

事件驱动系统真正的接口不是 Topic 名，而是事件的 Schema。生产者以为「加个字段」是小事，消费者却按旧结构反序列化——这类故障不抛异常、只静默错读，比服务间接口不兼容更难排查：服务调用不兼容至少会 500，消息错读可能几周后才发现对账不平。

Schema Registry 把契约从口头约定升级为可注册、可校验、可回滚的线上资源：写入前先按兼容性策略校验，通过后分配全局 ID；消费端凭消息头里的 ID 取回 schema，无需在每个消费者里硬编码结构。Kafka 三件套的分工是：C11.11 管消息路径 EOS，C11.24 管内嵌流处理，本题管契约演进。

裸 JSON / 字符串时代：字段靠人约定。加字段消费者忽略、删字段消费者拿到 null、改类型静默截断；Schema 只活在设计文档里，与线上消息无关。

Schema 前置：Avro / Protobuf 把结构写进 schema，支持紧凑二进制编码与形式化兼容判定——兼容性从「靠人吵」变成「可计算」。

集中注册：Confluent Schema Registry / Apicurio / AWS Glue Schema Registry 把版本集中托管，消息只带 schema ID（Magic Byte + 4 字节），载荷不再自描述，省带宽也省解析开销。

治理内建：兼容性策略（BACKWARD / FORWARD / FULL / NONE）、CI 期预检、变更审批与影响面分析进入发布门禁；Registry 与 Catalog 联动做血缘与质量。

兼容性四象限：判定方向由「谁先升级」决定，不是由格式决定。生产默认 BACKWARD（新消费者读旧数据），因为消费端通常先发版；涉及跨团队订阅多、升级节奏不可控时用 FULL。

Avro 的关键约束是默认值：字段必须有 default 才能安全新增/删除；无默认值的字段变更在多版本混跑时直接反序列化失败。Protobuf 的关键约束是字段号：号永不复用、reserved 标记废弃号、optional/explicit 显式区分「未设置」与「零值」——否则 0 与缺省无法区分，业务判空逻辑会错。

Wire Format：消息 = Magic Byte(0x0) + 4 字节 schema ID + 序列化载荷。ID 全局单调整，同一 schema 演进不更新 ID（ID 标识一个已注册版本，不是逻辑主题）；这一条决定了「回滚消息」在协议层天然可行。

// 生产端：注册 + 带 ID 序列化（Spring Kafka 示意）
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, KafkaAvroSerializer.class);
props.put("schema.registry.url", registryUrl);
props.put("auto.register.schemas", false);   // 生产禁自动注册
props.put("use.latest.version", true);      // 用已审批版本
props.put("value.subject.name.strategy", TopicNameStrategy.class);

// 消费端：先取最新可用 schema，再反序列化历史数据
props.put("specific.avro.reader", true);       // 生成 SpecificRecord 而非 GenericRecord
props.put("latest.compatibility.strict", false);

CI 期预检：把兼容性校验前移到构建阶段，而不是等上线时被 Registry 拒绝。Avro 用 avro-tools / schema-registry-maven-plugin 的 test-compatibility 目标；Protobuf 用 buf breaking --against 与主干对比。流水线失败即阻断合并，比生产侧拦截便宜一个数量级。

变更流程：新字段一律可空 + 给默认值 → 生产者先发版（双写新老字段窗口）→ 观测消费端无异常 → 清理旧字段（先 reserved 再物理删除）。破坏性变更（改类型、改语义、复用字段号）不走同 Topic，新建 Topic + 双写迁移 + 到期下线。

追问 1：Schema Registry 会不会成为新的单点？ 会，但故障模式可控。Schema Registry 是控制面（写少读多）：客户端本地缓存 schema，正常运行不依赖实时调用；Registry 宕机只影响新 schema 注册，已缓存消费者可继续。高可用按控制面设计：多副本 + 客户端缓存 + 本地降级读缓存；但绝不能把 auto.register 当兜底，否则契约治理形同虚设。

追问 2：它能替代 API 版本治理吗？ 不能，覆盖范围不同。Registry 管的是「异步消息契约」，同步接口（REST/gRPC）另有版本策略（URL 版本、Header 协商、buf breaking + gRPC 兼容规则）。两者的共同原则是一致的：只做向后兼容的增量演进，破坏性变更走新通道。可参考 C10.02 的接口演进讨论。

追问 3：字段删了就删了，为什么要先 reserved？ 因为历史消息还在。Kafka 保留期内（或数据湖里）旧数据仍可按老 schema 解析，一旦字段号被新字段复用，同一块字节会有两种解释——这是最隐蔽的一类数据事故。Protobuf 的 reserved 5; 与 Avro 的语义删除（保留字段、停用访问）都是为了让「号」与「名」不可回收。

• 生产开 auto.register.schemas：谁先发版谁定契约，兼容性策略形同废止；应该关掉，改为流水线预注册 + 审批。
• 用 NONE 策略「先跑起来」：一旦有消费者依赖旧结构，NONE 会把不兼容变更放进生产。NONE 必须配到期时间与清理任务。
• Subject 命名策略不统一：TopicNameStrategy 与 RecordNameStrategy 混用会产生多套 subject，兼容性校验跨了个空——同一点位必须固定一种策略，写进脚手架。
• Avro 加字段不给默认值：旧消费者遇到新消息直接反序列化异常；且在 BACKWARD 策略下会被 Registry 拒绝，团队常误判为「Registry 有问题」。
• 把 registry 当配置中心用：往里塞业务开关、塞大 JSON 配置，读写次数与体积失控；Registry 只放 Schema。
• 只在生产侧校验：CI 不预检，问题在上线时才暴露，回滚代价放大；预检成本极低，必须进主流水线。

上线门禁：① 兼容性策略按 Topic 显式声明（默认 BACKWARD，共享 Topic 用 FULL）；② auto.register.schemas=false 且 schema 走审批注册；③ CI 含 test-compatibility / buf breaking 且失败阻断合并；④ 破坏性变更必须新建 Topic 并附迁移与下线时间表。

可观测：Registry 侧看注册/校验失败次数、各 subject 版本数与最后变更时间；消费侧看反序列化失败率（应恒为 0，非 0 即契约被绕过）、UnknownSchemaException 计数、schema ID 分布（可发现仍在跑旧版本的实例）。

回滚：schema 版本不可删（删除会破坏历史数据可读性），回滚只能前滚到兼容版本；进程侧回滚到上一镜像即可，因为新 schema 兼容旧代码。数据修复需按 schema ID 分组重放，而非整 Topic 重放。

官方主线：Confluent Schema Registry API / Compatibility Types（BACKWARD、FORWARD、FULL 及 TRANSITIVE 变体）；Apache Avro Spec — Schema Resolution 与 default 语义；Protocol Buffers Language Guide — Field Numbers / reserved / optional 语义。

与全站交叉：Kafka 消息语义与 EOS 见 C11.11；Kafka Streams 内嵌处理见 C11.24；流处理引擎对照见 C11.25；接口演进与版本治理见 C10.02。

GraphQL 要解决的不是「REST 不好」，而是客户端取数形状不可预知：移动端、小程序、Web 三端各要不同字段组合，靠后端不断加接口必然膨胀成接口泥潭。GraphQL 把取数形状的决策权交给客户端，服务端只声明「有哪些字段、怎么解析」。

代价同样明确：单一入口 + 递归查询 = 查询复杂度不可预知。因此 GraphQL 的工程难点不在语法，而在治理——如何限制深度与复杂度、如何把 N+1 压成批量、如何做字段级授权、如何让查询可缓存。本题谈 Java 侧（Spring for GraphQL / graphql-java）的落地与治理边界。

REST 时代：一个页面调 5~10 个接口，过度取数与请求瀑布（Waterfall）并存；后端为聚合需求不断加 /summary 类定制接口。

BFF 聚合：为每端建 BFF 做聚合，缓解了前端问题但把复杂度搬到后端，BFF 数量随端数增长。

GraphQL 单入口：Schema 即契约，客户端按需取数；Facebook 2015 开源后由 GraphQL Foundation 托管规范。

规模化治理：Federation（多团队各自维护子图）、持久化查询（Persisted Query，只允许白名单查询）、复杂度预算与深度限制成为生产标配；Java 侧以 spring-graphql + graphql-java 为主流。

Schema First：.graphqls 是唯一契约，先定 Schema 再写 Resolver。类型系统天然承担文档与校验职责，且可生成前端类型（Codegen）。

Resolver 与 N+1 的根因：字段级解析意味着 [Order] → customer 会对每个 Order 各查一次用户，1 个查询变成 N+1 次下游调用。DataLoader 是解药：在同一事件循环 tick 内收集 key，合并为一次批量查询并做请求级缓存——这是 GraphQL 与普通 RPC 最大的工程差异点。

安全模型：单一端点让「按 URL 做鉴权」失效，必须下沉到字段级授权——Resolver 内校验当前用户对目标对象的访问权，而不是只校验「能不能调这个接口」。同时必须限制深度（maxDepth）、复杂度（按字段配权重累加）、查询体量，否则一次嵌套查询可打穿数据库。

// Spring for GraphQL：DataLoader 批量解 N+1
@SchemaMapping(typeName = "Order", field = "customer")
public CompletableFuture<Customer> customer(Order o, DataLoader<Long, Customer> loader) {
    return loader.load(o.getCustomerId());   // 同 tick 内自动合并为一次批量查询
}

@Bean
BatchLoaderRegistry.RegistrationSpec<Long, Customer> customerLoader(CustomerRepo repo) {
    return batchLoaderRegistry -> batchLoaderRegistry
        .forType("customerLoader", Long.class, Customer.class)
        .registerMappedBatchLoader((ids, env) ->
            Mono.just(repo.findByIds(ids)));   // 一次 IN 查询
}

查询防护配置：MaxQueryDepthInstrumentation 限制嵌套深度（建议 8~10）；MaxQueryComplexityInstrumentation 按字段权重累计复杂度并设预算；MaxQueryComplexityCalculator 可给列表字段乘倍数，防止 first: 1000 类放大。分页强制游标（Relay Cursor Connections），禁止无界列表。

持久化查询：客户端上传查询得 hash，运行期只接受已知 hash——这是 GraphQL 抗滥用最有效的一招，同时把 POST 变成可缓存语义，并让「谁在查什么」可审计。新增查询走白名单审批，未注册查询直接拒绝。

与同步接口分工：服务间内网调用继续用 gRPC（契约强、性能优、流式支持好）；GraphQL 只放在面向多端的最外层 BFF，内部仍调 gRPC/REST，避免把 GraphQL 渗透到全链路导致排障困难。

追问 1：N+1 用缓存解决不行吗？ 部分可以，但缓存解决的是「重复读」，N+1 的本质是「批量机会被拆散」。同一个请求里 100 个不同 ID 的查询，缓存全部 miss，仍是 100 次调用。DataLoader 做的是合并（1 次 IN 查询），缓存做的是复用，两者互补而不是替代。

追问 2：为什么强调字段级授权？ 因为端点级授权失效后，攻击面被放大：一个 viewer 角色可以构造查询拿到本不该见的字段（如 order.internalNote）。规则是每个敏感字段的 Resolver 必须自带权限判定，并对返回集合做租户过滤；授权失败返回 null 还是抛错要显式设计（抛错更安全，返回 null 会被当成「无数据」）。

追问 3：GraphQL 适合内部服务间调用吗？ 通常不适合。内网调用要的是强契约、低开销、流式与背压——gRPC 更合适。GraphQL 的价值在客户端形状不可预知；内网调用方是确定的，引入 GraphQL 只会增加解析开销与排障成本。

• N+1 未治理就上线：列表页 QPS 打满下游，表现为「数据库 CPU 高但慢 SQL 不多」——因为是大量小查询。上线前必须做 DataLoader 覆盖度检查。
• 无深度/复杂度限制：一段 friends { friends { friends { ... } } } 即可耗尽内存与连接池；这是 GraphQL 最典型的拒绝服务面。
• 只做端点鉴权：认为「登录了就能查」；字段级越权在单端点模型下不会被网关拦截。
• Schema 破坏性变更：直接删字段或改类型，客户端 Codegen 产物与运行期不一致；规则同 Protobuf——只增不改，废弃字段用 @deprecated 标注并给下线期。
• 把 GraphQL 当数据库查询语言：在 Resolver 里透传客户端过滤条件拼 SQL，等于把查询权限交给前端；过滤条件必须服务端白名单化。
• 错误处理含糊：GraphQL 允许「部分成功」（data 有值、errors 有项），若不约定 errors 语义，前端会把降级数据当完整数据渲染。

上线门禁：① 已启用深度 + 复杂度双限制且给出预算值；② 所有列表字段有分页上限，无界列表为 0；③ 敏感字段 Resolver 含权限校验，且有越权用例回归；④ 持久化查询白名单已启用（或说明为何不启用）；⑤ DataLoader 覆盖率检查通过。

可观测：按 operation name 打点（P50/P95/P99 延迟、错误率）、字段级耗时热力图（定位慢 Resolver）、复杂度分布（防止客户端逐步加码）、DataLoader 平均批量大小（接近 1 说明合并失效）。

降级：非核心字段提供 fallback（返回 null 并标记 degraded），核心字段失败则整查询失败；对高频查询结果做请求级缓存；流量异常时可临时下调复杂度预算而非直接摘除端点，保留可观测性。

官方主线：GraphQL Specification（graphql.org）——类型系统、执行语义、Validation 规则；Spring for GraphQL Reference——@SchemaMapping、DataLoader 注册、Instrumentation；graphql-java 文档——MaxQueryDepth / MaxQueryComplexity 实现。

与全站交叉：同步接口选型与 gRPC 对照见 E08.04；网关与鉴权见 C10.02；API 安全与越权防护见 E09.01。