本人在淘天集团移动中间件团队亲历过不少有意思的项目, 本文总结了其中之一: 轻量级流程引擎;
同其他已在编排领域深内耕多年的框架相比, 本流程引擎还显得十分稚嫩, 甚至有重复造轮之嫌, 然而与老前辈们相比它又确实有一点点自己的小个性, 也确实满足了特定场景下的业务需求, 该篇即总结一下本人在相关领域内的一些实践经历;
(注: 本文涉及的相关代码已做过脱敏及混淆, 不一定能实际执行)

背景 & 简介

淘系移动中间件的新版控制台, 在各种日常运维和配置发布场景中, 广泛使用了形态多变、需求各异的多种工作流程; 为了尽可能轻量化并降低对外部系统的依赖, 新控制台在最近几年的迭代与演进中, 沉淀出了一套轻量而不失丰富、多变但不显冗余的流程引擎, 并在多条产品线中落地生根, 包括但不限于:

• API 网关 (MTOP) 的接口统一发布
• API 网关的接口归属应用迁移
• SSR (Server-Side-Render) 投放的流量接入
• 统一接入层 (tengine) 流量防护 (前置限流等) 配置下发
• 统一接入层的金丝雀 (精细) 路由配置下发
• 面向大语言模型的 MCP Server 统一发布

该平台使用的流程引擎 (以下简称本框架) 的能力发展主要经历了以下几个阶段:

1. 早期孵化: 早在流量网关只能于旧控制台上运维的时代是没有流程的概念的, 所有关于 API 的操作都是零散、互相无关、没有统筹规划的; 感谢前同事在当时做了最初的尝试, 搭建起了本框架的内核雏形, 规范了 Task - Step 交互的 基本原则, 本人也是在这个阶段接手了本项目;
2. 状态管控: 当业务开始产生真实的诉求, 本框架顺势补齐了自身最大的缺陷: 状态一致性保证; 因为业务可能会随时取消一个发布任务, 当任务中的部分步骤已经执行成功时, 无任何补偿措施地取消该任务会导致资源整体状态不一致, 这是业务所不能容忍的, 于是本框架推出了 具备补偿机制 的版本, 这意味着本框架实现了对流程生命周期的可控托管, 意味着本框架在生产环境基本可用;
3. 可定义化: 当新控制台计划将发布任务的概览以可视化透出到界面时, 本框架又遇到了任务定义职责不清的问题: 任务的定义被隐式混淆于任务实例的构建逻辑中, 这导致无法给用户提供一个全图视野的任务概览, 只能随任务的执行而逐步展开, 这让可视化的效果大打折扣; 本框架以此为契机将 任务定义 (Task Definition) 显式独立出来, 任务定义和任务实例 (Task Instance) 的生命周期至此彻底切割;
4. 产品化尝试: 随着新控制台能力的不断丰富, 越来越多场景的工作流程亦试图接入进来, 此刻接入成本的问题开始凸显, 本框架于是迈出产品化尝试的第一步: 在任务定义的基础之上进一步实现了 可配置化, 允许在 diamond 等平台独立维护任务定义, 降低流程的管理成本, 增强任务定义的动态性;

时至今日, 本框架已形成了一个五脏俱全的小生态, 为上文提及的业务场景持续输出技术价值; 同其他已在编排领域深内耕多年的框架相比, 本框架还显得十分稚嫩, 甚至有重复造轮之嫌, 然而与老前辈们相比它又确实有一点点自己的小个性, 也确实满足了特定场景下的业务需求, 不过以当前的产品化水平, 只能支撑部门内部的需求, 如果想要更进一步, 还有很长的路要走;
 
本文便以分享为目的, 介绍一下本框架的设计思想, 抛砖引玉;

基本原理

设计哲学

本框架具备微内核、高可扩展的特性:

• 内核层仅定义了 Task 和 Step 的极简模型:

  1 2 3 4 5 6

  TaskCtx StepCtx 1 ^ ^ 1 | | 1 | | 1 Task ----> Step 1 *

• 在内核之上做丰富的能力扩展:

  • 编排能力扩展: SequentialStep (串行步骤)、CompositeStep (并行步骤);
  • 有状态能力扩展: StatefulTask、StatefulStep (会激活存储模块);
  • 可补偿能力扩展: CompensableTask、CompensableStep (允许取消任务时自动调度用户配置的补偿步骤);
  • 自动调度能力扩展: AutoExeStep (会激活调度模块);
  • 第三方异步流程扩展: 对接外部系统, 比如安全审核、changefree 等;

• 扁平的继承结构, 优先使用组合的方式拼搭任务能力;

模型细节

核心模型

这里有一个细节需要解释: 如上图, Task 和 TaskStep 被实际设计为 1:1 的关系, 这是为了更清晰地区分任务和步骤的职责边界, 例如:

• 假设 Task 和 TaskStep 是 1:N 的关系:
  • 那么 task 就需要感知 step 的编排逻辑, 要负责去按照约定顺序调度多个 step;
  • 当任务执行了一半后需要取消, task 还需要额外负责处理这 N 个 step 补偿的顺序关系, 亲自编排补偿步骤 $step^´$;
• 而在 1:1 的关系下:
  • task 只需要无脑去调用 step.execute(), 至于 step 如何去处理内部多个子步骤的调用顺序, 完全不用关心;
  • 当任务执行了一半后需要取消, 一个 CompensableTask 只需要规范其步骤也必须是 CompensableTaskStep, 就可以将步骤的补偿逻辑屏蔽, 全权交给 CompensableTaskStep 自己去实现;

下文中我们将直接被 task 关联依赖的 step 称为: Task 直隶的统领型步骤;

执行模式

本着轻量化的原则, 该框架在任务调度之外不会使用额外资源维护各任务的状态, 并且为了简化调度逻辑, 当一个任务被派发到执行器, 一律从任务入口处重新执行, 任务 (及相关步骤) 是否需要加载状态的判断、以及实际的状态拉起动作 被延迟到其真正执行的那一刻, 这意味着:

• 当一个任务 (及其步骤) 未配置任何 stateful 能力的扩展, 则该任务的每次调度都等于从头重新执行一遍, 即使之前的调度已经对该任务的部分步骤完成了执行;
• 当一个任务 (及其步骤) 配置了 stateful 能力扩展, 则任务及相关步骤的每次执行都会保存其最新状态, 在任务的下一次调度中, 已执行的步骤会加载恢复到最新状态, 并从最新状态继续执行, 如果步骤已经执行成功, 执行器会越过该步骤并按照编排顺序执行下一个步骤;

无状态的执行模式有助于降低任务调度间隙的内存消耗, 由于大部分任务都是 IO 密集型的, 如果后期能进一步对执行的调用模型做一些反应式的改造, 本框架将能撑起很高的任务并发;

作用域 & 约束关系

• TaskStep 由 Task 生成, Task 的生命周期 > TaskStep 的生命周期;
• 一个 TaskStep 只能属于一个 Task, 一个 Task 可以基于组合型的 TaskStep 派生出多个 TaskStep;
• 一个 Task 只有一个 TaskContext, 多个 TaskStep 可以共享同一个 TaskContext;
• 一个 TaskStep 只有一个 TaskStepContext, 不同 TaskStep 之间的 TaskStepContext 互相隔离, 不能共享;

 
由以上约束关系可以得知 TaskStep 间的通信方式如下:

• 同一个 TaskStep, 在不同的调度批号 (schedulerx 任务) 中, 可以通过对应的 TaskStepContext 传递信息;
• 不同的 TaskStep, 可以通过其所在 Task 的 TaskContext 传递信息;

状态流转

任务的状态取决于步骤的状态, 步骤的状态取决于步骤自身或其嵌套的子步骤的执行状态;

• 任务的状态流转:

  

  task status machine

• 步骤的状态流转:

  

  step status machine

组合优先架构

本框架以 “组合优先” 的理念为指导, 提供了 steteful、autoExecute、compensate (补偿) 等多种可以拼搭组合的能力;

TaskStep 的组合能力

TaskStep 的组合继承结构

以下是几种经典的能力:

• StatefulTaskStep: 有状态能力增强

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

  public StatefulTaskStep(AbstractTaskStep delegatedTaskStep, TaskPersistence taskPersistence) { super(delegatedTaskStep); this.taskPersistence = taskPersistence; // 恢复步骤状态 recoverTaskStep(); } @Override public TaskStepResult execute() { try { val taskStepResult = delegatedTaskStep.execute(); setStatus(taskStepResult.getStatus()); return taskStepResult; } finally { // 保存步骤状态 saveTaskStep(); } } private void saveTaskStep() { TaskStepSnapshot taskStepSnapshot = TaskStepSnapshot.builder() .taskId(taskId) .name(delegatedTaskStep.getName()) .type(delegatedTaskStep.getType()) ....... .build(); taskPersistence.saveTaskStep(taskStepSnapshot); } private void recoverTaskStep() { val taskStepSnapshot = taskPersistence.recoverTaskStep(taskId, delegatedTaskStep.name); val taskStepContext = taskStepSnapshot.getTaskStepContext(); delegatedTaskStep.saveStepContext(taskStepContext); }

  其本质是:

  • 在构造步骤实例时恢复被代理步骤上次执行后的上下文;
  • 在被代理步骤执行完成后保存步骤最新的上下文;

  

• AutoExecuteTaskStep: 自动调度能力增强
  AutoExecuteTaskStep 实现自动调度的原理是借助 StatefulTaskStep 将 autoExecute 类型的 taskStep 上下文写入持久层, 然后由 AutoExecuteScheduler 扫描持久层追踪正在执行中的 autoExeTaskStep, 并执行相应 task;

  1 2 3 4 5 6 7 8 9 10 11 12 13

  public AutoExecuteTaskStep(String name, AbstractTaskStep scheduledTaskStep, TaskPersistence taskPersistence) { super(name, StatefulTaskStep.wrap(new DoAutoExecuteStep( name, scheduledTaskStep), taskPersistence)); } private static final class DoAutoExecuteStep extends DelegateTaskStep { @Override public String getType() { return "autoExecute"; } }

  可以看到, AutoExecuteTaskStep 自身就极致利用了组合代理的能力, 通过两个维度的简单代理实现自动调度的核心能力:

  • 第一个维度: 通过一个间接的 DoAutoExecuteStep 代理用户真实的业务步骤, 并标识自身的 type 为约定的 autoExecute, 以插桩的形式指引调度器识别出需要自动调度的 task;
  • 第二个维度: 通过 StatefulTaskStep 代理 DoAutoExecuteStep, 以持久化 DoAutoExecuteStep 的状态, 从而允许调度器扫描持久层列举需要自动调度的 task;

  

 
能力的组合

框架提供了便于拼搭 stateful 与 autoExecute 能力的包装工具:

1
2
3
4
5
6
7
8
9
10

public static AbstractTaskStep wrap(AbstractTaskStep taskStep,
                                    TaskPersistence taskPersistence) {
    return new StatefulTaskStep(taskStep, taskPersistence);
}

public static AbstractTaskStep wrap(AbstractTaskStep taskStep,
                                    TaskPersistence taskPersistence) {
    return new AutoExecuteTaskStep("AutoExecute:" + taskStep.getName(),
                taskStep, taskPersistence);
}

如果用户希望一个步骤既要拥有状态持久化的能力, 同时也要拥有被自动调度的能力, 可以如下实现:

1
2
3
4
5
6
7
8

AbstractTaskStep wrap(AbstractTaskStep taskStep) {
    // stateful
    AbstractTaskStep taskStep = StatefulTaskStep.wrap(
        taskStep, taskPersistence);
    // autoExecute
    taskStep = AutoExecuteTaskStep.wrap(taskStep, taskPersistence);
    return taskStep;
}

执行以上代码将会得到如下状态:

stateful 和 autoExecute 能力组合的步骤上下文

当然下文会讲到, 用户并不需要如此亲自编写代码, 本框架提供了便捷的方式帮用户自动生成相关能力叠加;

 
补充: 高级能力
除了 stateful、autoExecute 等常用能力外, 框架内还有其他高级能力使用了该组合机制, 比如与补偿相关的顺序执行可补偿步骤 (SequentialCompensableTaskStep) 和 并行执行可补偿步骤 (CompositeCompensableTaskStep), 这些补偿相关的步骤没有被设计为直接对用户开放, 而是通过更友好的方式被上层包装, 下文将会具体介绍;

Task 的组合能力

与 TaskStep 类似, Task 也提供了诸如 stateful、compensate 等多种可以拼搭组合的任务能力; 不过与 TaskStep 略有不同的是:

• TaskStep 是直接面向具体业务细节的, 不同的业务场景差异很大, 灵活度太高, 无法沉淀出一套通用的步骤范式, 只能提供一些最基础的 stateful、autoExecute 等原子能力;
• 而 Task 不是面向具体业务细节的, 它是可以被更抽象的场景所概括描述的, 比如说内部系统的审批流、配置发布的流程等, 所以框架针对这类通用运维场景沉淀出了一个最佳实践OpsTask / CompensableOpsTask;

• OpsTask 的组合链路: StatefulTask (AbstractTask);
• CompensableOpsTask 的组合链路: StatefulTask (CompensableTask);

OpsTask 维护了通用运维任务所需要的业务强类型数据结构 globalBusData 及对应的序列化/反序列化方法 taskDataSerDeser, 在任务生命周期中的每一次调度, 都会在初始化时帮用户恢复最新的数据, 调度结束后再将更新后的数据状态持久化;
CompensableOpsTask 是 OpsTask 的可补偿版本, 除了 OpsTask 的基本能力外, CompensableOpsTask 还会帮助用户管理补偿编排逻辑;
OpsTask / CompensableOpsTask 帮用户设定好了组合模式, 可以开箱即用, 用户直接继承使用即可, 当然如果用户有自定义需求, 也可以选择自己去组合 stateful 等原子能力;
根据目前的实际使用情况, 大部分业务的任务都选择了具有补偿能力的 CompensableOpsTask, 只有少数简单的没有数据一致性要求的场景选择了 OpsTask, 暂没有业务选择自定义 Task;

任务取消的补偿机制

由于任务中存在多个步骤, 在执行任意一个步骤时, 用户都可能取消, 此时当前步骤之前的步骤已经执行成功, 当前步骤之后的步骤均未执行; 要想让任务取消后保持任务执行前的状态, 就需要引入回退补偿机制: Hector & Kenneth: Sagas (1987)

自适应补偿的简单示例

由用户定义自己的步骤 $(S_1, S_2, ….. S_n)$, 及对应的补偿步骤 $(S_1^´, S_2^´, ….. S_n^´)$, CompensableTask 负责根据当前状态自适应地生成补偿步骤, 比如:
某任务共有 $S_1、S_2、S_3$ 三个步骤, 用户执行完成了 $S_1、S_2$ 后取消任务, 则此时任务的步骤链路变成: $S_1 \Rightarrow S_2 \Rightarrow S_2^´ \Rightarrow S_1^´$;

 
Task 和 TaskStep 分别在各自的维度实现了补偿能力:

TaskStep 的补偿原理

补偿体系的继承结构

CompensateAwareTaskStep

对补偿有感知能力的步骤, 着重点是步骤的性质分解, 表达的是对任务中的 (原子或复合) 步骤 能够识别自身已执行和待补偿 (子) 步骤的一种抽象;
顾名思义, 该接口在本框架的语境下就是能够识别出已被执行的 “逻辑步骤”, 以及能够推导出已执行步骤对应的 “补偿逻辑步骤”:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public interface CompensateAwareTaskStep { /** * 当所在任务被取消时, 提取 originStep 已经被执行的 "逻辑步骤" * 如果 originTask 没有被执行, 应当返回 Optional.empty() */ Optional<AbstractTaskStep> executedTaskStep(); /** * 当所在任务被取消时, 基于 originStep 的状态生成对应的补偿 "逻辑步骤" * 如果 originTask 不需要被补偿, 应当返回 Optional.empty() */ Optional<AbstractTaskStep> compensateTaskStep(); /** * 原始的 taskStep, 本小节不讨论该方法 */ AbstractTaskStep originTaskStep(); }

对于原子步骤、串行步骤、并行步骤这三种类型, 将分别围绕各自的编排特性完成对以上接口的实现:

• 原子步骤的补偿版本: AtomicCompensateAwareStep:
  感知补偿的原子步骤的逻辑最简单, 需要用户同时给定目标步骤 (normalStep) 和对应的补偿步骤 (compensateStep):

  • executedTaskStep 方法: 当 normalStep 已执行则返回 normalStep, 否则返回 Optional.empty();
  • compensateTaskStep 方法: 当用户没有配置补偿步骤 (NoneTaskStep) 返回 Optional.empty(), 或者当 normalStep 的状态需要补偿, 则返回 compensateStep;

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

    class AtomicCompensateAwareStep implements CompensateAwareTaskStep { private final AbstractTaskStep normalStep; private final AbstractTaskStep compensateStep; @Override public Optional<AbstractTaskStep> executedTaskStep() { return normalStep.getStatus().isProcessedStatus() ? Optional.of(normalStep) : Optional.empty(); } @Override public Optional<AbstractTaskStep> compensateTaskStep() { if (!TaskStepStatus.needCompensate(normalStep.getStatus())) { return Optional.empty(); } // 补偿步骤类型为占位步骤, 标识用户认为无需针对目标步骤补偿 if (compensateStep instanceof NoneTaskStep) { return Optional.empty(); } return Optional.ofNullable(compensateStep); } }

• 串行步骤的补偿版本: SequentialCompensableTaskStep:
  感知补偿的串行步骤的逻辑是在原子补偿步骤的基础上, 结合了自身串行编排的特征, 需要用户同时给定 n 组目标步骤和对应补偿步骤的配对 $(S_1, S_1^´), (S_2, S_2^´) ….. (S_n, S_n^´)$, SequentialCompensableTaskStep 基于这 n 组配对构建一个 List< CompensateAwareTaskStep> compensateAwareSteps:

  • executedTaskStep 方法: 对 compensateAwareSteps 中的元素遍历执行 executedTaskStep 方法获取一个 executedSteps 列表, 当列表不为空, 以此构建一个新的 SequentialTaskStep 返回, 否则返回 Optional.empty();
  • compensateTaskStep 方法: 对 compensateAwareSteps 中的元素遍历执行 compensateTaskStep 方法获取一个 compensateSteps 列表, 当列表不为空, 对此做 reverse 构建一个反向的 SequentialTaskStep 返回, 否则返回 Optional.empty();

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

    public class SequentialCompensableTaskStep extends DelegateTaskStep implements CompensableTaskStep, CompensateAwareTaskStep { @Override public Optional<AbstractTaskStep> executedTaskStep() { List<AbstractTaskStep> executedSteps = Compensates.getExecutedSteps(compensateAwareSteps); return CollectionUtils.isNotEmpty(executedSteps) ? Optional.of(buildCompensatingSequentialTaskStep(executedSteps)) : Optional.empty(); } @Override public Optional<AbstractTaskStep> compensateTaskStep() { final List<AbstractTaskStep> compensateSteps = Compensates.getCompensateSteps(compensateAwareSteps); final List<AbstractTaskStep> compensateStepChain = Lists.reverse(compensateSteps); return CollectionUtils.isNotEmpty(compensateStepChain) ? Optional.of(buildCompensatingSequentialTaskStep(compensateStepChain)) : Optional.empty(); } }

• 并行步骤的补偿版本: CompositeCompensableTaskStep:
  感知补偿的并行步骤的逻辑是在原子补偿步骤的基础上, 结合了自身并行编排的特征, 需要用户同时给定 n 组目标步骤和对应补偿步骤的配对 $(S_1, S_1^´), (S_2, S_2^´) ….. (S_n, S_n^´)$, CompositeCompensableTaskStep 基于这 n 组配对构建一个 List< CompensateAwareTaskStep> compensateAwareSteps:

  • executedTaskStep 方法: 对 compensateAwareSteps 中的元素遍历执行 executedTaskStep 方法获取一个 executedSteps 列表, 当列表不为空, 以此构建一个新的 CompositeTaskStep 返回, 否则返回 Optional.empty();
  • compensateTaskStep 方法: 对 compensateAwareSteps 中的元素遍历执行 compensateTaskStep 方法获取一个 compensateSteps 列表, 当列表不为空, 以此构建一个新的 CompositeTaskStep 返回 (不需要 reverse, 因为是并行的, 不区分次序), 否则返回 Optional.empty();

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

    public class CompositeCompensableTaskStep extends DelegateTaskStep implements CompensableTaskStep, CompensateAwareTaskStep { @Override public Optional<AbstractTaskStep> executedTaskStep() { List<AbstractTaskStep> executedSteps = Compensates.getExecutedSteps(compensateAwareSteps); return CollectionUtils.isNotEmpty(executedSteps) ? Optional.of(new CompositeTaskStep(name, taskContext, executedSteps)) : Optional.empty(); } @Override public Optional<AbstractTaskStep> compensateTaskStep() { final List<AbstractTaskStep> compensateSteps = Compensates.getCompensateSteps(compensateAwareSteps); return CollectionUtils.isNotEmpty(compensateSteps) ? Optional.of(new CompositeTaskStep(name, taskContext, compensateSteps)) : Optional.empty(); } }

 

CompensableTaskStep

该接口是步骤补偿体系的另一个维度, 着重点是步骤的链路整合, 表达的是对任务中的 (原子或复合) 步骤基于当前的状态自适应生成 同时具备已执行和待补偿步骤的逻辑链路的抽象;

1 2 3 4 5 6

public interface CompensableTaskStep extends TaskStep { /** * 基于原有 taskStep 的当前状态, 针对性地生成具备补偿原有 taskStep 能力的新的步骤链路 */ TaskStep generateCompensableTaskStep(); }

• 串行补偿链路整合的实现: SequentialCompensableTaskStep:

  • 对 compensateAwareSteps 中的元素遍历分别生成已执行和待补偿的两部分, 并拼接两者构建新的 SequentialTaskStep;

    1 2 3 4 5 6 7 8 9 10 11 12 13 14

    public class SequentialCompensableTaskStep extends DelegateTaskStep implements CompensableTaskStep, CompensateAwareTaskStep { @Override public TaskStep generateCompensableTaskStep() { // 提取已执行过的普通步骤 final List<AbstractTaskStep> executedSteps = Compensates.getExecutedSteps(compensateAwareSteps); // 根据原有步骤的执行状态生成适应性的补偿步骤 final List<AbstractTaskStep> compensateSteps = Compensates.getCompensateSteps(compensateAwareSteps); final List<AbstractTaskStep> compensatingStepChain = Lists.newArrayList(executedSteps); compensatingStepChain.addAll(Lists.reverse(compensateSteps)); return buildCompensatingSequentialTaskStep(compensatingStepChain); } }

• 并行补偿链路整合的实现: CompositeCompensableTaskStep:

  • 并行补偿的链路整合没有做到如语义上的绝对并行, 而是出于实现复杂度的考虑, 降级为: 已执行和待补偿两部分 在整体上先后串行执行, 而各自在内部并行执行;
  • 所以其实现是将 executedSteps 和 compensateSteps 两个 CompositeTaskStep 串为一个整体的 SequentialTaskStep;

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

    public class CompositeCompensableTaskStep extends DelegateTaskStep implements CompensableTaskStep, CompensateAwareTaskStep { @Override public TaskStep generateCompensableTaskStep() { // 提取已执行过的普通步骤 final List<AbstractTaskStep> executedSteps = Compensates.getExecutedSteps(compensateAwareSteps); // 根据原有步骤的执行状态生成适应性的补偿步骤 final List<AbstractTaskStep> compensateSteps = Compensates.getCompensateSteps(compensateAwareSteps); final CompositeTaskStep executedCompositeStep = new CompositeTaskStep(name, taskContext, executedSteps); final CompositeTaskStep compensateCompositeStep = new CompositeTaskStep(COMPENSATE_STEP_DEFAULT_PREFIX + name, taskContext, compensateSteps); // 为了使用统一的接口 (CompensateAwareTaskStep) 以便于管理, composite compensable step 的补偿逻辑 // 采用了由 executedStep + compensateStep 串联起的 sequentialTaskStep final List<AbstractTaskStep> compensatingStepChain = ImmutableList.of(executedCompositeStep,compensateCompositeStep); return new CompensatingSequentialTaskStep(name, taskContext, compensatingStepChain); } }

由以上描述可知, SequentialCompensableTaskStep 和 CompositeCompensableTaskStep 既是 CompensateAwareTaskStep 又是 CompensableTaskStep, 这意味着它们:

• 既可以作为一个直接由 Task 直隶的统领型步骤, 从整体上去整合普通链路与补偿链路;
• 又可以作为一个局部的被嵌套的子步骤, 提供基本的步骤拆分能力, 由上层统领型步骤去统一调度;

如此便可编织出一张允许任意递归灵活嵌套的步骤执行网络, 从而拥有强大的自适应补偿能力;

本框架目前只有复合型步骤实现了该接口, 为了简化实现, 原子步骤 AtomicCompensateAwareStep 未实现该接口, 因为原子步骤在语义上可以转化为只有一个子步骤的 SequentialTaskStep 或 CompositeTaskStep;

 
最后还需要额外补充一下: SequentialCompensableTaskStep 和 CompositeCompensableTaskStep 除了实现了上述两个核心接口外, 还直接继承了 DelegateTaskStep, 它们代理的 TaskStep 逻辑如下:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public static SequentialCompensableTaskStep buildSequentialCompensableTaskStep(String name, TaskContext taskContext, List<Boolean> autoExecuteConfigs, List<CompensateAwareTaskStep> taskSteps) { final List<AbstractTaskStep> normalTaskSteps = taskSteps.stream() .map(CompensateAwareTaskStep::originTaskStep) .collect(Collectors.toList()); final SequentialTaskStep sequentialTaskStep = new SequentialTaskStep(name, taskContext, normalTaskSteps, autoExecuteConfigs); return new SequentialCompensableTaskStep(name, taskContext, sequentialTaskStep, taskSteps); } private SequentialCompensableTaskStep(String name, TaskContext taskContext, SequentialTaskStep delegatedTaskStep, List<CompensateAwareTaskStep> compensateAwareSteps) { super(delegatedTaskStep); this.name = name; this.taskContext = taskContext; this.compensateAwareSteps = compensateAwareSteps; }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public static CompositeCompensableTaskStep buildCompositeCompensableTaskStep(String name, TaskContext taskContext, List<CompensateAwareTaskStep> taskSteps) { final List<AbstractTaskStep> normalTaskSteps = taskSteps.stream() .map(CompensateAwareTaskStep::originTaskStep) .collect(Collectors.toList()); final CompositeTaskStep compositeTaskStep = new CompositeTaskStep(name, taskContext, normalTaskSteps); return new CompositeCompensableTaskStep(name, taskContext, compositeTaskStep, taskSteps); } private CompositeCompensableTaskStep(String name, TaskContext taskContext, CompositeTaskStep delegatedTaskStep, List<CompensateAwareTaskStep> compensateAwareSteps) { super(delegatedTaskStep); this.name = name; this.taskContext = taskContext; this.compensateAwareSteps = compensateAwareSteps; }

也即: 将 List 中每个 step 的原始部分执行逻辑剥离, 单独重组为逻辑上的 SequentialTaskStep 或 CompositeTaskStep, 并将其作为被代理的逻辑步骤, 这就使得 SequentialCompensableTaskStep 和 CompositeCompensableTaskStep 在没有取消时可以像正常步骤一样执行, 任务取消时可以优雅切换到补偿模式;

Task 的补偿原理

CompensableTask 是任务级补偿能力的核心: CompensableTask 只接受关联一个 CompensableTaskStep, 这就使得 CompensableTask 的补偿逻辑十分简洁:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

public abstract class CompensableTask extends AbstractTask { protected TaskResult executeTask() { try { if (isCancelling()) { return executeCompensatedStep(); } if (canExecute()) { return executeNormalStep(); } else { return new TaskResult(getTaskId(), getStatus()); } } catch (Exception e) { if (isCancelling()) { final TaskStep compensableTaskStep = this.compensableTaskStep.generateCompensableTaskStep(); compensableTaskStep.onFailure(e); } else { compensableTaskStep.onFailure(e); } return new TaskResult(getTaskId(), TaskStatus.FAILURE, e, e.getMessage()); } } @Override public void cancel() { // 幂等返回 if (TaskStatus.CANCELED.equals(getStatus()) || TaskStatus.CANCELLING.equals(getStatus())) { return; } // 终态不允许取消 if (TaskStatus.SUCCESS.equals(getStatus())) { throw new UnsupportedOperationException("已执行成功的任务无法取消"); } try { compensableTaskStep.onInterrupt(); getTaskContext().put(TASK_CANCEL_MARK, true); final TaskResult compensateResult = executeCompensatedStep(); setStatus(compensateResult.getStatus()); } catch (Exception e) { setStatus(TaskStatus.FAILURE); compensableTaskStep.onFailure(e); throw new RuntimeException("cancel task error, errorDetail: " + e.getMessage(), e); } } private TaskResult executeCompensatedStep() { final TaskStep compensableTaskStep = this.compensableTaskStep.generateCompensableTaskStep(); final TaskStepResult taskStepResult = compensableTaskStep.execute(); ...... } private TaskResult executeNormalStep() { final TaskStepResult taskStepResult = compensableTaskStep.execute(); ...... } }

• 只需重写 AbstractTask 的两个方法: executeTask() 和 cancel();
• 对于 cancel() 方法:
  1. 先 Interrupt 原步骤;
  2. 执行 compensableTaskStep.generateCompensableTaskStep().execute();
• 对于 executeTask() 方法:
  • 如果当前未取消: 执行 compensableTaskStep.execute();
  • 如果当前正在取消中: 执行 compensableTaskStep.generateCompensableTaskStep().execute();

除此外无需任何多余的逻辑, 便能实现任务级的补偿能力;

复杂 case 举例

图示说明:

• 状态缩写:

  • P (PENDING)
  • R (RUNNING)
  • SK (SKIPPED)
  • SU (SUCCESS)
  • INT (INTERRUPTED)

• 步骤标号: 用于区分步骤次序

  • 数字: 单一步骤 (或并行包装步骤) 的次序;
  • 字母: 并行包装步骤内各个真正并行步骤的次序;
  • 上标 ´ : 表示对应数字 (字母) 步骤的补偿步骤;

本节用具体示例表示几种复杂任务拓扑结构下, 当任务取消后的瞬时状态:

• case 1:
  2 号步骤中的两个子步骤是并行的;
  SKIP 状态的步骤在补偿阶段被自适应跳过;

  

  取消后的步骤状态

• case 2:
  取消前 a、b、c 号步骤作为整体, 和 d 号步骤是并行的;
  取消后两条并行链路继续并行补偿;

  

  取消之前的步骤状态

  

  取消后的步骤状态

任务定义的演进

截止到本节之前, 其实本框架最核心的能力已经介绍完毕; 但是很明显, 如果让用户直接去裸用上述接口, 还是有一定理解及操作成本的, 本框架需要给用户提供一种易理解易上手的友好型交互使用模式;

定义层 (Definition Layer)

本框架考虑了将复合型步骤 (串行编排、并行编排) 的概念对用户屏蔽, 让用户专注于自身的业务步骤定义以及业务步骤间的关系管理, 为此引入了一个概念: Stage (阶段), 并将步骤定义下放到 Stage 内:

1 2 3 4 5 6 7 8 9 10 11 12 13

class Stage { val name: String val order: Integer val steps: List<Step> } class Step { // type = ATOMIC 时有意义 val configs: StepConfigs // type = NESTED 时有意义 val stages: List<Stage> val type: ATOMIC | NESTED }

其行为特征如下:

• 同一个 stage 内的多个 step 并行执行;
• 不同 stage 按照 stage 的 order 从小打到依次执行;
• stage 有两种类型的 step:
  • 原子步骤: 不能再继续分解;
  • 嵌套步骤: 嵌套另一个 stage, 递归定义;

虽然从本质上讲, 一个 stage 等效于本框架中的 CompositeTaskStep, 多个 stages 按 order 排列等效于本框架中的 SequentialTaskStep, 但从语义上看, 对用户暴露 阶段 的概念更贴合人类的思维习惯, 用户可以基于 Stage 这个 middle layer 组织业务步骤之间的关系;

Stage 的数据结构

虽然本框架可以构建任意嵌套层级的任务结构, 但若将 Stage 作为一个整体来观察, 无论处于嵌套结构中的哪个位置, 同一层级同一作用域内的多个 stage 一定是线性排列的; 另外还需考虑到 Stage 的表达能力要同时兼顾补偿机制, 具备同时编排用户的普通 stage 和对应的补偿 $stage^´$ 的能力;

以上意味着 Stage 的数据结构要满足:

• 支持正反两个方向 (正向普通和逆向补偿) 的序列编排;
• 支持从任何一个正向的 stage 节点切换到补偿节点 $stage^´$ 并反向流转;

  1 2 3 4

  [end] <- stage1´ <- stage2´ <- stage3´ ^ ^ ^ | | | [start] -> stage1 -> stage2 -> stage3 -> [end]

本框架为此构造了一种 “mirrored double list” 结构, 释义如下:

• mirrored: 普通 stage 与补偿 $stage^´$ 操作对象相同、操作内容相反, 构成轴对称镜像;
• double: 表示正向普通与逆向补偿两条任务推进的动线;

实现逻辑如下:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// 泛型参数 DepType 的含义在下一节解释 class Stage<DepType> { val steps: List<Step> val compensate: CompensateStage var next: Stage<DepType> } class CompensateStage<DepType>: Stage<DepType> { CompensateStage(compensateSteps: List<Step>) { super(compensateSteps, CompensateStage<>()) } CompensateStage() { super(nil, nil) } }

其中的关键是两个指针 next 和 compensate:

• 普通 $stage_n$ 的 next 指向下一个 $stage_{n+1}$, $stage_n$ 的 compensate 指向与自己对应的补偿 $stage_n^´$;
• 补偿 $stage_n^´$ 的 next 指向下一个补偿 $stage_{n-1}^´$, 补偿 $stage_n^´$ 的 compensate 指向空;

 
附: 本框架基于 linked list 去编织 stage 镜像双链:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

public <DepType> Stage<DepType> buildStage(List<StageConfig> configs) { Stage<DepType> currentStage = null; Stage<DepType> previousStage; // 最终要返回的目标: 步骤定义链的头指针 Stage<DepType> entranceStage = null; for (int order = 0; order < configs.size(); order++) { previousStage = currentStage; final StageConfig stageConfig = configs.get(order); currentStage = doBuildStage(order, configs.size(), stageConfig); if (previousStage != null) { previousStage.next(currentStage); } else { entranceStage = currentStage; } } return entranceStage; } private <DepType> Stage<DepType> doBuildStage(int order, int totalStageCount, StageConfig stageConfig) { final List<Step<DepType>> steps = Lists.newArrayListWithExpectedSize( stageConfig.getSteps().size() * 2); for (StepConfig step : stageConfig.getSteps()) { final Pair<Step<DepType>, Step<DepType>> normalAndCompensates = step.getType().buildSteps(order, totalStageCount, stageConfig, step); steps.add(normalAndCompensates.getLeft()); steps.add(normalAndCompensates.getRight()); } return Stage.buildCompensable(steps.toArray(new Step[0])); } public static <DepType> Stage<DepType> buildCompensable(Step<DepType>... steps) { final List<Step<DepType>> normals = Lists.newArrayList(); final List<Step<DepType>> compensates = Lists.newArrayList(); for (int i = 0; i < steps.length / 2; i++) { final Step<DepType> normal = steps[2 * i + 0]; final Step<DepType> compensate = steps[2 * i + 1]; normals.add(normal); compensates.add(compensate); } return new Stage<>(normals, new CompensateStage<>(compensates)); }

任务实例的解释执行

定义层作为一个中间桥接层, 向上对接用户的任务/步骤定义, 向下负责将用户的定义 interpret 为具体的任务实例, 具体的原则如下:

• 当一个 stage 没有配置对应的补偿 stage^´, 本框架会使用一个空实现的 NoneTaskStep 对其补偿逻辑占位;
• 从入口 stage 开始, 本框架会通过 stage 的 next 指针遍历, 依据 Stage 中的 Step 定义, 构建具体的 TaskStep 实例:

  • 本框架引入了一个 step builder 的概念, 表示如何驱动具体步骤的实例化;
    -泛型 DepType 表示构建步骤实例所依赖的具体资源, 用户可以定义一个总线性质的类去承载整个任务中所有步骤的依赖对象, 并由该任务的所有步骤统一依赖 (上文 OpsTask 即遵循此约定);

  • step builder 的引入有效降低了中间定义层和步骤实例构造之间的耦合, 为 “一次编写, 处处使用” 的步骤复用场景打下了基础 (例如 API 统一发布和 API 归属应用迁移 两种场景, 依托 step builder 灵活的适配能力, 实现了步骤的 100% 复用);

  • 另外, step builder 也为 定义的配置化 创造了条件: 实例构建的具体细节被屏蔽, 取而代之的是, step builder 的签名允许以极简的形式转化为任务定义的文本配置;

    1 2 3 4 5 6 7 8 9 10 11

    class AtomicStep<DepType>: Step<DepType> { val taskStepBuilder: TaskStepBuilder<DepType> } class NestedStep: Step<DepType> { val nestedStage: Stage<DepType> } interface TaskStepBuilder<DepType> { fun build(String name, TaskContext taskContext, DepType stepDependencies): TaskStep }

  • (stage 内并行编排) 扫描 stage 分别生成 normal 和 compensate 步骤实例的过程:

    • 一个 stage 内如果只有一个 step 定义, 解释为步骤实例直接返回;
    • 一个 stage 内如果有多个 step 定义, 将其分别解释后的步骤实例组合为一个 CompositeTaskStep;
• (stage 间串行编排) 当扫描完一段完整的 stage 链, 因为这一步可能是 CompensableTask 初始化时直接调用的, 需要返回一个 CompensableTaskStep (当然也可能不是, 比如嵌套 stage 的初始化):
  • 如果只生成了一对 normal / compensate 步骤, 既可以构造一个 CompositeCompensableTaskStep, 也可以构造一个 SequentialCompensableTaskStep (参考此处说明);
  • 如果生成了多对 normal / compensate 步骤, 按序传入, 构造一个 SequentialCompensableTaskStep;

任务实例的可视化

对任务定义的独立化, 还有一个有益的用途是解除任务实例的生命周期对任务定义的生命周期的绑架:

• 本框架的 执行模式 决定了一个任务中的步骤只有被执行了才会记录其状态, 否则不会留下任何痕迹;
• 如果没有任务定义的独立化, 那么当查询一个任务实例的执行概要就只能列出该任务已经执行过的步骤, 无法列出未执行的步骤, 用户无法建立起对任务执行进度的全局观, 有损用户体验;

任务定义的生命周期和任务实例的生命周期并不相同, 缺乏任务定义的视角、单纯基于任务实例执行现状去构造任务执行概要, 只能取得管中窥豹的效果; 而当任务定义被剥离出来后, 本框架可以基于任务定义的快照, 在此之上填充各步骤的状态概要, 从而得以更友好地向用户展示任务执行进度;

定义的配置化

即使上一小节引入了对用户更友好的 Stage 概念, 但这只是降低了用户对步骤编排的理解成本, 却并未降低用户的使用操作成本; 为此本框架在上一节的基础之上更进一步, 实现了任务定义的全面配置化, 比如以下任务定义 DSL:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84

[ { "stageName": "前置准备", "steps": [ { "normal": { "name": "APIChangefreeRecord", "taskStepBuilder": "APIPublishCfRecordStep$APIPublishCfRecordStepBuilder", }, "compensate": { "name": "APIChangefreeRecordCancel", "taskStepBuilder": "APIPublishCfRecordCancelStep$APIPublishCfRecordCancelStepBuilder", } }, { "normal": { "name": "SecurityAudit", "taskStepBuilder": "SecuritySubmitStep$SecuritySubmitStepBuilder", } } ] }, { "stageName": "API 发布", "steps": [ { // 嵌套 stage 定义 "stages": [ { "stageName": "元信息安全生产灰度引流", "steps": [ { "normal": { "name": "APIMetaGrayPublish", "taskStepBuilder": "MetaGrayPublishStep$MetaGrayPublishStepBuilder" }, "compensate": { "name": "APIMetaGrayCompensate", "taskStepBuilder": "MetaGrayCompensateStep$MetaGrayCompensateStepBuilder" } } ] }, { "stageName": "元信息正式发布", "steps": [ { "normal": { "name": "APIMetaPublish", "taskStepBuilder": "MetaPublishStep$MetaPublishStepBuilder" }, "compensate": { "name": "APIMetaCompensate", "taskStepBuilder": "MetaCompensateStep$MetaCompensateStepBuilder" } } ] } ] }, { "normal": { "name": "APIRoutePublish", "taskStepBuilder": "APIRoutePublishStep$APIRoutePublishStepBuilder" }, "compensate": { "name": "APIRouteCompensate", "taskStepBuilder": "APIRouteReverseStep$APIRouteCompensateStepBuilder" } } ] }, { "stageName": "后置处理", "steps": [ { "normal": { "name": "APIBaselineRecord", "taskStepBuilder": "BaseLineRecordStep$BaseLineRecordStepBuilder" } } ] } ]

上述配置本框架将会为之生成如下任务结构:

• 正向流程:

  1 2 3

  APIChangefreeRecord -| |- APIMetaGrayPublish --> APIMetaPublish -| |---->| |----> APIBaselineRecord SecurityAudit -------| |------------ APIRoutePublish ------------|

• 补偿流程 1:

  1 2 3

  APIChangefreeRecord -| |----> APIChangefreeRecordstage´ SecurityAudit -------|

• 补偿流程 2:

  1 2 3

  APIChangefreeRecord -| |- APIMetaGrayPublish --> APIMetaPublish -| |- APIMetaPublish´ --> APIMetaGrayPublish´ -| |---->| |---->| |----> APIChangefreeRecordstage´ SecurityAudit -------| |------------ APIRoutePublish ------------| |------------- APIRoutePublish´ ------------|

为了最大限度地迎合普通人的直观思维习惯, 本框架允许以自然结对的方式配置 normal 和 compensate 步骤定义, 即: 用户无需关注任务取消时补偿步骤应当如何编排, 只管按照正向流程的自然顺序依次定义即可, 本框架全权负责将 DSL 配置翻译为以 Stage 为核心的中间定义层, 再将中间定义层转译解释为真实的任务实例;

产品化展望

截止到本节之前, 本框架目前已实现的所有能力均已介绍完毕; 然而在产品化方面, 本框架仅仅处于最初级的阶段, 以下是本框架接下来可以发展的几个方向;

任务定义域

版本化

每一次任务定义的修改都应该被赋予一个唯一的版本, 而每一个任务实例也都应绑定到唯一的任务定义版本, 并伴随实例的整个生命周期;

如果没有版本化, 当任务定义修改 (比如前置增加一个步骤), 已执行或正在执行中的实例会因未曾执行过该新步骤而出现不可预知的结果; 而绑定任务定义版本的实例, 每次调度都会通过既定版本的任务定义解释执行, 与其他版本隔离, 保证执行结果的确定性;

低代码

本框架当前使用 diamond 维护任务定义的配置内容,「上 diamond 编写任务定义的 DSL」这种方式只能说在部门内部小规模使用勉强可以满足, 但要推广到外部就不够看了;
当前业内有影响力的流程引擎大多支持了 ISO 业务流程建模 BPMN 2.0 标准, 本框架也同样应当拥抱该业界规范, 实现图形化表达和 DSL 定义之间的互相转换, 从而允许开发者直接在图形界面上通过拖拽组件的方式实现便捷的流程编排, 更进一步降低接入及运维成本;
由于本框架编排流程的底层数据结构是基于「横(串行)」和「竖(并行)」两种基本逻辑单元组合交织而成, 对于任何 “无冗余依赖型的有向无环图” 都可以通过这种逻辑方式表达 (反例: 令 $G=(a,b,c | a \rightarrow b, b \rightarrow c, a \rightarrow c)$, 由于 c 对 b 有依赖, 因而 c 对 a 的依赖被 b 对 a 的依赖所阻塞, 导致 c 对 a 的依赖是冗余的);
当一个 DAG 的数据结构被本框架标准化后, 就可以很方便地接入补偿机制, 实现生命周期的自动托管, 这也算是本框架的一个小小优势吧;

调度域

分布式化

本框架当前虽已经沉淀了诸多可复用的常见步骤类型及通用实践经验, 但它们的代码都在淘系中间件控制台的 git 仓库内, 目前只能跑在控制台本地环境, 这意味着想要复用就必须局限在控制台内开发新的任务流程, 这极大限制了本框架的推广;
诚然, 轻量级的特性使得本框架也可以走 jar 包分发的路线, 允许用户在自己的应用中自主集成 sdk, 但如此就形成一个个应用孤岛, 无法聚集起生态, 管控亦没有抓手, 反馈与改进难以闭环, 因此走分布式化执行的路线是一个非常值得考虑的方向;

分布式调度模型

在这个领域内最值得参考的就是 SchedulerX2, 事实上 SchedulerX2 最近也推出了自己的流程编排能力: 一个分布式调度领域的框架进军编排领域是一个积累到一定程度自然而然的事情, 同理一个编排领域的框架涉足分布式调度领域, 某种角度上看也属殊途同归;

产品定价

流程引擎的服务定价是一件比较复杂的事情, 因为服务对象的形态差异较大, 对资源的要求不尽相同, 很难为每一个类型的任务给出合适精确的定价; 但得益于 无状态的执行模式, 本框架尽可能抹平了异构任务之间的复杂度差异 (结合 分布式化调度 效果更加), 从而有可能只基于任务特征及步骤特征构建一个极简的定价模型:

$$ P(type) = \alpha \cdot \vec{\gamma_t} \cdot \vec{\lambda_t} + (1 - \alpha) \cdot \sum_{n=1}^{cnt(type)} \vec{\gamma_{sn}} \cdot \vec{\lambda_{sn}} + \omega $$

其中:

• $P(type)$: 某类型任务的单价 (单位 元/次);
• $cnt(type)$: 指定类型的任务下步骤的编排数量;
• $\alpha$: 任务分量的定价权重;
• $\vec{\gamma_t}$ 与 $\vec{\lambda_t}$: 任务的特征向量及特征对应的定价因子;
• $\vec{\gamma_{sn}}$ 与 $\vec{\lambda_{sn}}$: 任务中指定步骤的特征向量及特征对应的定价因子;
• $\omega$: 损耗常量 (云/网络 等资源的成本分摊);

为简化计算, 我们只取最核心的特征分量, 令:

$$ \vec{\gamma_t} = \begin{bmatrix} steteful \\ stateless \end{bmatrix}, \vec{\gamma_{sn}} = \begin{bmatrix} stateful \\ stateless \\ autoExe \\ manualExe \end{bmatrix} $$

结合存储服务和调度服务分摊给本框架的费用, 就可以为每一种类型的任务分别算出各自的定价; 以上模型在保证本产品运营不亏损的前提下, 尽可能兼顾了公平;

参考资料

• Hector & Kenneth: Sagas (1987)
• ISO 标准: 业务流程建模 BPMN 2.0
• SchedulerX2

https 的实现涉及了众多密码学算法的应用, 为了保证信息传输的绝对安全衍生出了众多概念, 环环相扣, 逻辑无比严密, 值得详细地梳理与记录;

密码学基础知识

对称加密

定义一个密钥 secretKey, 用其对明文进行加密, 同理用这把密钥也可以对密文进行解密, 也就是说加密和解密，可以用同一个密钥, 速度比较快;
常用的对称加密方法有:

• DES
• 3DES
• AES

非对称加密

定义一对公钥 publicKey 和私钥 privateKey, 可以使用私钥加密、公钥解密, 同理也可以使用公钥加密、私钥解密, 速度非常慢;
常见非对称加密方式的有:

• RSA (最常用)
• DSA

非对称加密的用途:

• 加密 / 解密;
• 签名 / 验签 (身份认证);

单向加密

不可逆加密, 对明文的加密产生一个密文, 不能再通过密文解出对应的明文, 一般用于计算消息摘要;
常见的单向加密有:

• MD5
• SHA (SHA-128、SHA-256 等)

秘钥交换协议

• Diffie-Hellman:
  • 依赖于计算有限群的离散对数的困难性;
  • 运算速度相对快;
  • 支持前向保密;
• ECDHE: 基于椭圆曲线 ECC 的 Diffie-Hellman, 使用椭圆曲线上的点作为公钥和私钥
  • 依赖于计算椭圆曲线离散对数的困难性;
  • 运算速度比传统的 DH 更快, 安全性也更高;
  • 支持前向保密;
• RSA: 除了用于非对称加密, 也可用于秘钥交换
  • 依赖于大数分解问题的困难性;
  • 运算速度相对慢;
  • 不支持前向保密;

安全传输的原理

https 安全传输的过程用一句话概述为: 用对称加解密实现内容的安全传输, 用非对称加解密 (或专用秘钥交换协议) 实现对称加密秘钥的安全传输;
这么做主要是出于性能的考虑:

• 由于目标报文内容巨大, 故使用速度快的对称加密;
• 而对称加密秘钥的传输内容简短, 故可以容忍使用速度慢的非对称加密 (或专用秘钥交换协议);

 
以下我将用 6 个最关键的问题, 基于自然语言描述安全传输的核心逻辑:

• 如何将通信内容安全地传输给对方?
  答: 用对称加密的方式进行通信;
• 如何将对称加密的秘钥 secretKey 安全地传输给对方?
  方案一: 使用专用的秘钥交换协议 (例如 ECDHE, 两端通过特定算法分别自主计算出相同的秘钥);
  方案二: 用非对称加密的方式:
  1. 服务端将公钥 publicKey 明文传输给客户端;
  2. 客户端随机生成一个对称加密的秘钥 secretKey;
  3. 客户端用 publicKey 对 secretKey 加密, 并传给服务端;
  4. 服务端用 privateKey 解密出 secretKey;
• 服务端如何将真实的公钥 publicKey 传输给对方?
  答: 使用 CA 颁发的数字证书验证 publicKey 真伪:
  1. 服务端将包含公钥 publicKey 的证书发送给客户端;
  2. 客户端验证证书的真伪;
  3. 客户端从证书中提取网站的公钥 publicKey;
• 客户端如何验证数字证书的真伪 (防篡改)?
  答: 客户端对数字证书验签:
  1. 客户端用 CA 的公钥对证书中的签名解密得到摘要 D1;
  2. 客户端用证书中的摘要算法, 对证书内容计算出摘要 D2;
  3. 若 D1 == D2 则验证通过;
• 如何确保 CA 的公钥是真实的?
  答: CA 为自己的公钥专门生成的证书已提前内置在操作系统中了, 无需从网络中获取;
• 如何生成域名的数字证书?
  答: 网站提交指定材料, 向 CA 机构申请数字证书:
  1. CA 向证书中写入摘要算法、域名、网站的公钥等重要信息;
  2. CA 根据证书中写入的摘要算法, 计算出证书的摘要;
  3. CA 用自己的私钥对摘要进行加密, 计算出签名;
  4. CA 生成一张数字证书, 颁发给指定域名;
  5. 网站的管理员, 把证书放在自己的服务器上;

 
用一张图来形象概括上述 6 个问题提及的知识点:

https 的简要过程

数字证书

数字证书 (Digital Certificate) 是一种用于验证网络实体 (如个人、设备、服务器等) 身份的电子凭证, 类似于现实生活中的身份证或护照; 它基于公钥基础设施 (PKI，Public Key Infrastructure) 技术, 确保通信双方的身份真实性 (确保客户端访问的是真实的网站而非钓鱼网站) 和数据传输的安全性;

证书的内容

一个标准的数字证书通常包含以下信息:

• 持有者信息: 名称、组织等;
• 颁发者信息: 证书颁发机构 (CA) 的名称;
• 有效期: 证书的生效和过期时间;
• 公钥 (Public Key): 用于加密数据或验证签名;
• 数字签名: 由 CA 对证书内容进行签名, 防止伪造;

zshell.cc 证书内容

证书颁发机构

由上文可知, 由于窃听者 / 中间人的存在, 我们无法信任公网传输的任何信息, 这就形成了一个无解的猜疑链:

• 我怎么知道秘钥 secretKey 是否安全得传给对方?
• 我怎么知道对方传输的公钥 publicKey 是真实的?
• 如果要引入一个权威的公证人来证明 publicKey 的真实性, 我又如何知道这个公证人本身是没问题的?
• ……

要想打破这个猜疑链, 就必须要在源头上建立起对公证人权威的信任, 于是现代主流的操作系统都内置了主流证书颁发机构 (Certificate Authority) 的公钥, 只要我们使用的是正版操作系统, 就可以放心使用 CA 的 publicKey 来验证服务端传输的数字证书的真伪;

SSL / TLS 协议

TLS (Transport Layer Security) 传输层安全性协议, 它的前身是 SSL (Secure Sockets Layer) 安全套接层, 是一个被应用程序用来在网络中安全的通讯协议, 它实现了将应用层的报文进行加密后再交由 TCP 进行传输的功能;
TLS 基于 TCP, 实现了两个应用进程之间的安全传输连接:

• 完成身份鉴别 (鉴别服务端或客户端);
• 安全地共享一对协商密钥 (主密钥) 来进行对称加密;
• 保证报文的完整性, 防篡改;
• 预防恶意的重放攻击;

协议栈总览

• TLS 握手协议: 用于加密、身份鉴别;
• TLS 记录协议: 用于保证报文的完整性和防重放攻击;

TLS 1.3 协议栈

TLS 1.3 协议栈_English

TLS 握手

TLS 握手协议用于实现在进行安全传输之前必要的身份鉴别和协商共享密钥:

TLS 1.3 handshake protocol brief

握手协议的信息交换是在没有加密的情况下进行的, 在这一协议中所收发的所有数据都可能被窃听者窃听 (当然此阶段不传输真实报文, 即使被窃听也不用担心);

密码套件 (Cipher Suites)

由上文我们知道, https 的建立过程涉及到如下四个逻辑:

• 密钥交换 (Key Exchange): 生成需要的密钥;
• 身份认证 (Authentication): 验证 Server 身份;
• 对称加密 (Symmetric Encryption): 为数据传输提供保密性;
• 摘要算法 (Hashing): 数据完整性校验;

以上每个部分都可以使用不同的、可替换的算法实现, 如果要穷举所有的组合可能性, 其组合总数将会爆炸, 为了在 client - server 两端就以上四点快速达成一致协议, 就产生了密码套件的概念 (TLS 协议不允许用户对局部某个算法进行自定义, 只能协商选择一个密码套件);
在 Internet Assigned Numbers Authority 中详细枚举了所有的密码套件, 以下是几种常见的密码套件:

密码套件举例

其中关于秘钥交换协议的对比:

• RSA:
  • RSA 的客户端 pre-master 需要通过网络传输发送给服务端, 一旦服务器的私钥泄露, 会话密钥就会被破解;
  • TLS 完成四次握手后, 才能进行应用数据传输;
• ECDHE (更加先进):
  • 秘钥是两端独立计算出来的, 不会在网络上传输, 不存在直接泄漏的可能;
  • 客户端可以不用等服务端的最后一次 TLS 握手, 就提前发出加密的 HTTP 数据, 节省了一个 RTT;

现代主流的 TLS 1.3 已淘汰 RSA, 默认使用 ECDHE 作为秘钥交换协议;

TLS 握手协议详细过程

• pre-master secret: 客户端随机生成的一个 48 字节 (384 位) 的临时秘钥, 其格式为:
  • 前 2 字节为 TLS 版本号 (如 0x0303 代表 TLS 1.2);
  • 后 46 字节为随机数据;
• pre-master 的安全传输:
  • RSA 秘钥交换: 非前向保密;
  • ECDHE 秘钥交换: 前向保密;
• master secret: 生成最终对称加密秘钥的 secret
  • client / server 互相明文交换 random 随机数;
  • 通过伪随机函数 PRF 生成: PRF(pre-master, "master secret", client.random + server.random)

TLS 握手协议的详细过程如下:

TLS 1.3 handshake protocol detail

多级秘钥: pre-master / master

由上图可见, TLS 的秘钥交换协议并非直接交换对称加密秘钥或相关 secret, 而是区分出了 pre-master / master secret, 如此设计的原因如下:

1. 提高安全性, 防止密钥单一依赖:

   • master Secret 依赖更多随机因素:
     • master secret 由 Pre-master secret + 客户端随机数 (ClientRandom) + 服务器随机数 (ServerRandom) 通过 PRF (伪随机函数) 计算得出;
     • 如果直接传输 master secret，攻击者截获后就能直接解密通信。
     • 而通过 pre-master secret 计算 master secret, 增加了额外随机数 (ClientRandom 和 ServerRandom), 即使 pre-master 被破解, 仍需这两个随机数才能推导会话密钥, 提高安全性;
   • 防止重放攻击:
     • 如果 master secret 直接传输，攻击者可能记录握手过程并重放，导致相同的 master secret 被多次使用;
     • 但 master secret 是由握手阶段的随机数动态生成的，每次握手都会不同，即使相同的 pre-master secret 也无法恢复相同的会话密钥;

2. 增强前向保密:

   • pre-master secret 可以临时生成:
     • 在 TLS 1.2 及之前，如果使用 RSA 密钥交换，pre-master secret 可能被服务器私钥解密，导致历史通信被破解 (无 PFS);
     • 但 ECDHE/DHE 允许 pre-master secret 通过临时密钥计算得出，即使服务器私钥泄漏，也无法解密过去的 pre-master secret;
     • 如果直接传输 master secret, 则无法实现这种前向保密机制;
   • TLS 1.3 已淘汰 RSA 密钥交换, 默认使用 ECDHE, 确保 pre-master secret 具备 PFS;

3. 防止中间人篡改密钥:

   • master secret 依赖于握手阶段的随机数：
     • 如果攻击者试图篡改 ClientRandom 或 ServerRandom, 会导致双方计算出的 master secret 不同, 握手失败;
     • 而如果直接传输 master secret, 攻击者可能篡改它导致密钥被控制;

参考资料

• 通俗大白话，彻底弄懂 https 原理本质
• TLS协议详解
• SSL证书之密码套件总览
• Internet Assigned Numbers Authority
• HTTPS中的密钥交换协议
• 密钥交换算法（RSA、ECDHE）

我在阿里云万网购买的个人域名 zshell.cc, 原先 CNAME 到了 github pages 的域名, 由于地缘政治风险, 已无法通畅访问, 于是我将博客迁移到了国内的 开放原子 atomgit pages, 本文记录了我如何利用 cloudflare 将域名解析完美迁移到 atomgit 的过程;

国内域名托管商的限制

我的需求如下:

• 我想让用户使用 zshell.cc 域名访问我的博客, 同时不能重定向到 atomgit 给我分配的默认域名 zshellzhang.atomgit.net;
• atomgit pages 首页限制了必须要带上默认的 path (值为注册在 atomgit 的仓库名, 我的是 zshell), 那么当我访问 zshell.cc, 需要帮我重定向到 zshell.cc/zshell;

对此需求, 普通的 CNAME 解析已经不够用了, 必须使用隐式 URI 解析, 另外还存在当匹配部分 path 时替换为指定 path 的场景, 这已经属于比较高级的需求了;
原先我的域名解析托管在阿里云万网, 然而万网对于配置 URI 解析的前提是要求域名必须在国内备案, 而备案又要求域名必须绑定阿里云的服务器 (且要求服务器套餐费用不得低于 100 元/年);
很明显, 我是不可能在这种事情上花一分钱的, 于是只能另寻他路;

域名解析的迁移

首先登录 万网域名管理, 修改 DNS 服务器, 用 cloudflare 代替万网来托管域名解析:

同时在 cloudflare 控制台 配置 CNAME 规则:

定义 Worker 反向代理

编写反向代理逻辑 url-implict-redirect.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

/**
 * Welcome to Cloudflare Workers! This is your first worker.
 *
 * - Run "npm run dev" in your terminal to start a development server
 * - Open a browser tab at http://localhost:8787/ to see your worker in action
 * - Run "npm run deploy" to publish your worker
 *
 * Learn more at https://developers.cloudflare.com/workers/
 */
export default {
  async fetch(request) {
    const url = new URL(request.url);
    const path = url.pathname;

    // 目标域名（实际目标）
    const targetDomain = "https://zshellzhang.atomgit.net";

    // 处理路径：
    //   - / → 代理到 /zshell
    //   - /about → 代理到 /zshell/about
    //   - /zshell → 代理到 /zshell
    //   - /zshell/about → 代理到 /zshell/about
    const targetPath = path.startsWith("/zshell") ? path : `/zshell${path}`;
    const response = await fetch(`${targetDomain}${targetPath}`, {
      headers: request.headers
    });

    // 返回响应（保持原始URL）
    return new Response(response.body, {
      status: response.status,
      headers: response.headers
    });
  }
};

部署并监控 Worker 的状态: url-implict-redirect;

将域名绑定 Worker

效果如下:

2002 年 linux 2.5.44 发布了 epoll, epoll 是 linux 实现高并发网络 I/O 处理的基础, 但凡存在网络 I/O 的系统或框架 (比如 nginx、netty、kafka、redis 等) 都离不开 epoll;
因此学习 epoll 的原理对于应用开发者理解网络框架的运行原理有着巨大的帮助;

前置基础知识

DMA 与中断

当 NIC 网卡收到网络数据时的处理流程:

• 网卡通过 Direct Memory Access 将数据写到内核内存 (Ring Buffer 和 sk_buff);
• 网卡向 CPU 发出中断请求 (Interrupt Request, IRQ);
• 为解决频繁 IRQ 导致大量上下文切换的开销, 内核采用了请求预聚合技术 (N-API, 即 New API):
  • 内核的 napi_schedule 函数专门快速响应 IRQ, 只记录必要信息, 并在合适的时机发出软中断 softirq;
  • 内核的 net_rx_action 函数响应软中断, 从 Ring Buffer 中批量拉取收到的数据并处理协议栈, 填充 socket 再交付上层;

    

    net data transfer

linux: 一切皆文件

在 linux 系统中 “一切皆文件 (Everything is a file)” 是一个核心的设计理念,
linux 将所有资源 (无论是普通文件、目录、设备、网络套接字还是进程信息) 都抽象为文件的形式, 并以一个抽象层 (Virtual File System) 统一管理, 使得用户可以用统一的文件描述符处理各种资源:

• 普通文件：如文本文件、图片文件等;
• 目录：目录本身也被视为一种特殊的文件;
• 设备：硬件设备（如硬盘、键盘、显示器）被抽象为设备文件;
• 管道和套接字：用于进程间通信的管道和网络通信的套接字也可以像文件一样操作;
• 系统信息：例如 /proc 和 /sys 文件系统中的内容，提供对系统状态和内核参数的访问;

当我们使用 epoll 时, 内核会创建一个 struct eventpoll, eventpoll 也是文件系统中的一种资源类型;

文件系统的 wait queue

在 Linux 文件系统中，等待队列是一种内核同步机制，用于管理因某些条件未满足而需要等待的进程; 它广泛应用于文件 I/O 操作、设备驱动程序和网络通信中，尤其是在处理阻塞操作时:

• 当读取文件时，如果文件的数据尚未准备好 (如管道或设备文件), 进程会被加入到等待队列中;
• 当写入文件时，如果缓冲区已满，进程也会被加入到等待队列中;

当条件满足时 (如数据到达或缓冲区有空间可用) 内核会唤醒等待队列中的进程;

当我们使用 epoll 时, 我们主要与两种文件类型打交道: eventpoll 和 socket, 他们分别有自己的等待队列 (wq), 存放不同类型的资源:

• eventpoll 队列: 存放的是等待 IO 事件到来的进程;
• socket 队列: 存放的是 struct eventpoll;

linux 内核中通常用 wait_queue_head_t 双向链表类型来定义等待队列;

epoll 的数据结构

eventpoll

eventpoll 是 epoll 核心数据结构, 用于管理一个 epoll 实例的所有相关信息:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

struct eventpoll {
    struct rb_root rbr;             // 红黑树，存储所有注册的 epitem
    struct list_head rdllist;       // 就绪链表，存储当前就绪的 epitem
    wait_queue_head_t wq;           // 等待队列，用于阻塞调用 epoll_wait() 的进程
    
    spinlock_t lock;                // 保护 eventpoll 对象的自旋锁
    struct mutex mtx;               // 互斥锁，用于保护某些关键操作
    wait_queue_head_t poll_wait;    // 用于支持嵌套 epoll (epoll over epoll)
    struct epitem *ovflist;         // 溢出链表，用于处理边缘触发模式下的特殊情况
    struct user_struct *user;       // 用户信息，用于资源限制跟踪
    struct file *file;              // 指向与该 epoll 实例关联的文件对象
    int visited;                    // 用于标记是否访问过，避免循环嵌套
    ...
};

eventpoll 结构体主要成员如下:

• rbr: 用于记录用户注册的其所感兴趣的 socket 事件, 使用红黑树结构, 方便后续查找;
• rdllist: 当向 epoll 注册的 socket 事件发生后, 就绪队列会记录相关 socket 的读/写事件并返回给用户进程;
• wq: 当用户进程调用 epoll_wait 进入休眠后, 被挂在该等待队列, 用于注册事件发生时回调唤醒该进程;

epitem

epitem 是 epoll 另一个核心数据结构, 承载了相关文件描述符 (通常为 socket 描述符) 及其事件订阅信息:

• ffd: 通过 ffd.fd 可以获取目标文件描述符;
• event: 事件类型, 常用如下: EPOLLIN (socket 可读), EPOLLOUT (socket 可写)

  1 2 3 4 5 6 7 8 9 10

  struct epitem { struct epoll_filefd ffd; // 文件描述符及其相关信息 struct epoll_event event; // 用户注册的事件信息 struct rb_node rbn; // 红黑树节点, 用于插入到红黑树 (rbr) 中 struct list_head rdllink; // 就绪链表节点, 用于插入到就绪链表 (rdllist) 中 struct eventpoll *ep; // 指向所属的 eventpoll 对象 ... };

除此之外, epitem 还有两个关键的字段:

• rbn: 作为一个 rb_node 类型 (linux 内核中通用的红黑树节点结构体), 它是 epitem 的字段, 同时也是 eventpoll rbr 红黑树的节点, eventpoll 通过内核中的一个通用宏定义 container_of, 可依据局部字段的地址计算出整个结构体的地址, 从而定位到 epitem;
• rdllink: 作为一个 list_head 类型 (linux 内核中通用的双向链表节点结构体), 与 rbn 类似, 它是 epitem 的字段, 同时也是 eventpoll rdllist 双向链表的节点, eventpoll 同样可以基于 container_of 根据 rdllink 字段定位到 epitem;

可以看到, epoll 的数据结构非常紧凑, eventpoll 的 rbr 和 rdllist 都是基于对 epitem 的引用构建的, 以最大限度地提升性能和节约内存:

struct eventpoll

epoll 数据结构的选型

有很多文章说, eventpoll 使用红黑树管理 socket 事件订阅只是一种实现方式, 也可以换成哈希表等其他高效的内存结构, 个人认为这是一个值得讨论的问题;
首先我们先梳理一下 epoll 面临的业务场景:

• 大量、高并发的 socket 请求: epoll 通常被服务端用于处理高并发的海量用户请求, 对低延迟要求很高;
• 低活跃的单个 socket 对象: 虽然有海量的请求连接到服务器, 但是对每一个具体的 socket 对象, 却活跃度很低, 在其生命周期的大部分时间内都不会产生 IO 事件;
• 朝生夕死的 socket 对象: socket 对象通常不会存活很久, 用户请求结束后会关闭连接;

总结一下业务特点就是:

• 存在 socket 的大量新增;
• 存在 socket 的大量删除;
• 对 socket 事件的响应处理必须要快;
• 虽然 socket 总量很大, 但是同一时刻发生 IO 事件的 socket 占总量比例不高;

再来看下不同数据结构对以上业务特点的支持能力:

• 红黑树:
  • 优点:
    1. 依托于链式结构无需大块的连续内存, 不管当前树结构有多么庞大, 创建新节点的成本都极低, 只要能找到一块可用内存就行;
    2. 删除节点的成本也相对可控, 通过有限的旋转和重新着色即可维护树的平衡;
  • 缺点:
    1. 查询时间复杂度是 O(logn), 当节点数量巨大, 查询性能会受一定影响;
• 哈希表:
  • 优点:
    1. 当内存足够大时, 查询 socket 的时间复杂度为 O(1);
  • 缺点:
    1. 需要申请一大片连续的内存用作文件描述符到 socket 的映射, 不够灵活;
    2. 当 socket 数量不断增长, hash 冲突的概率越大, 查询复杂度会劣化 (最差可劣化到 O(n));
    3. 如果需要扩容哈希表以减少 key 冲突, 需要申请一片新的连续内存, 并将旧的数据复制过去, 开销很大;
    4. 当请求流量进入低谷期时, 已扩容的哈希表如果不缩容, 会造成内存浪费; 如果缩容, 则又涉及数据复制, 增大开销;

 
综合考虑: 我们需要的理想数据结构是:

• 增删 socket 订阅事件、维护索引的成本要足够低;
• socket 事件订阅查询效率要尽可能高, 且要保持查询性能稳定, 不能因 socket 数量规模的急剧变化而产生明显劣化;

因此 linux 内核选择了查询性能十分稳定、对内存使用效率更高、使用方式更灵活的红黑树作为 eventpoll 索引 socket 订阅事件的数据结构;

补充: 内核常用结构和宏定义

• rb_node: 内核通用红黑树节点

  1 2 3 4 5

  struct rb_node { unsigned long __rb_parent_color; // 父节点指针和颜色标志 struct rb_node *rb_right; // 右子节点指针 struct rb_node *rb_left; // 左子节点指针 };

• rb_root: 内核通用红黑树根

  1 2 3

  struct rb_root { struct rb_node *rb_node; // 指向红黑树的根节点 };

• list_head: 内核通用双向链表节点

  1 2 3 4

  struct list_head { struct list_head *next; // 指向下一个节点 struct list_head *prev; // 指向前一个节点 };

container_of 宏定义:

1
2
3
4
5
6
7
8

/**
 * @param ptr：指向结构体中某个字段的指针 (如 rb_node 的地址)
 * @param type：结构体的类型 (如 struct epitem)
 * @param member：字段的名称 (如 rbn)
 */
#define container_of(ptr, type, member) ({                      \
    const typeof(((type *)0)->member) *__mptr = (ptr);          \
    (type *)((char *)__mptr - offsetof(type, member)); })

epoll 的执行逻辑

一般来说, 用户使用 epoll 的逻辑是:

• 调用 epoll_create, 创建对象;
• 调用 epoll_ctl, 订阅感兴趣的 socket 事件;
• 调用 epoll_wait, 等待订阅事件的发生;

epoll_create

1
2

#include <sys/epoll.h>
int epoll_create(int size);

进程调用 epoll_create 方法, 内核会创建出一个 struct eventpoll, 注册到文件列表中, 并将其文件描述符 epfd 返回给进程;

epoll_create

epoll_ctl

1
2
3
4
5
6
7
8
9

#include <sys/epoll.h>

/**
 * @param epfd  eventpoll 的文件描述符
 * @param op    EPOLL_CTL_ADD / EPOLL_CTL_MOD / EPOLL_CTL_DEL
 * @param fd    需要操作的文件 (比如 socket)
 * @param event 感兴趣的 socket 事件类型
 */
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

进程调用 epoll_ctl, 内核主要做了三件事:

1. 在内存中创建一个 struct epitem;
2. 插入目标 epitem 的 rbn 节点至 eventpoll 的 rbr 红黑树, 从而建立对 socket 事件订阅的高效查询;
3. 将 struct eventpoll 插入到目标 socket 等待队列, 用于 socket 接收到数据时回调以唤醒调用 epoll 线程;

insert_into_socket_wq

epoll_wait

1
2
3
4
5
6
7
8
9

#include <sys/epoll.h>

/**
 * @param epfd      eventpoll 的文件描述符
 * @param events    epoll 事件数组
 * @param maxevents 指定events 数组的大小, 即可以处理的最大事件数
 * @param timeout   若无目标事件发生, timeout 时间后返回 0
 */
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

关于 timeout 的设置:

• timeout > 0: 如果在指定的时间内没有事件发生, epoll_wait 将阻塞最多 timeout 毫秒;
  如果在此期间有事件发生则立即返回, 且返回值为触发事件的数量;
• timeout == 0: 不阻塞而是立即返回, 这种模式通常用于非阻塞检查, 适合需要快速轮询的场景;
• timeout == -1: 无限期阻塞, 直到至少有一个事件发生, 这是最常用的模式, 适合不需要定时功能的场景;
  绝大多数 I/O 多路复用场景, 尤其是长时间运行的服务端程序都应该是这个模式;

 
进程调用 epoll_wait 的过程:

• 如果没有注册的 socket 事件触发, 则进程被挂到 struct eventpoll 的等待队列, 然后休眠:

  

  epoll_wait_sleep

• 如果有注册的 socket 事件触发, 中断程序会唤醒 eventpoll 等待队列中的进程, 同时将目标 socket 挂到 eventpoll 的 rdllist 上并返回给目标进程:

  

整体事件/数据流

• 事件流图:
  • 红色数字: 调用 epoll_wait 并被挂起的执行顺序;
  • 蓝色字母: socket 事件触发唤醒进程并返回结果的执行顺序;

    

    epoll_wait events flow

     
• 数据流图:
  • 有 socket 事件触发, 从 rbr 中查找是否有注册的 socket 事件与之匹配;
  • 匹配到了 socket 事件, 则将 rbr 上对应的 epitem 选出, 组装到 rdlist 链中返回给应用进程;

    

    epoll_wait data flow

epoll 的触发模式

水平触发 (LT)

Level Trigger, 适合需要确保所有数据都被读取的场景:
当调用 epoll_wait 没有全部读完 socket 缓冲区, 下一次调用 epoll_wait 依然能够检测到 socket 就绪事件, 直到 socket 缓冲区数据被全部读完为止;

边缘触发 (ET)

Edge Trigger, 适合高效快速响应的场景:
当 socket 接收数据后, epoll rdlist 只会插入一次 socket 就绪事件, epoll_wait 检测到 socket 读事件后, 必须一次性把 socket 缓冲区数据全部读完, 否则数据可能丢失;

参考资料

• 如果这篇文章说不清epoll的本质，那就过来掐死我吧 (3)
• Linux epoll完全图解，彻底搞懂epoll机制
• 别再纠结 select 和 poll 了！epoll 才是 I/O 复用的顶流担当
• 深入理解 epoll

Raft (Resilience And Fault Tolerance) 于 2014 年由斯坦福大学的 Diego Ongaro 和 John Ousterhout 首次提出, 旨在用一种更简单易懂的算法来代替艰涩的 Paxos 算法;
本文将详细记录一下 Raft 的原理及各种细节;

基本概念

角色及状态机

raft 有三种角色:

• Leader: 负责发起心跳，响应客户端，创建日志，同步日志;
• Candidate: Leader 选举过程中的临时角色，由 Follower 转化而来，发起投票参与竞选;
• Follower: 接受 Leader 的心跳和日志同步数据，投票给 Candidate;

raft 的角色状态机

raft 的角色状态机

超时机制

raft 有两种超时时间:

• HeartBeat Timeout: 心跳超时, 用于 Leader 定期向 Follower 发送心跳, 维持自己的 Leader 地位; 心跳的作用是告诉 Follower: 我仍然是 Leader, 不要发起选举;
  • 实现方式: Leader 会定期 (默认 50 ms) 向所有 Follower 发送心跳请求 (AppendEntries RPC，即使没有日志条目也会发送);
• Election Timeout: 选举超时, 集群中的 Follower 节点在 electionTimeout 时间内没有收到 Leader 的心跳信息就会晋升为 Candidate, 触发新一轮的选主流程 (RequestVote RPC), 选举超时时间为随机值 150 ~ 300 ms;
  • Minimum Election Timeout: 最小选举超时, 为了防止 Follower 可能会在 Leader 仍然正常工作的情况下误判 Leader 失效从而发起不必要的选举, 通常至少要设为为 HeartBeat Timeout 的 3 ~ 5 倍, 默认 150 ms;

流程详解

状态同步

Leader 发起日志同步的 AppendEntries RPC 请求数据结构如下:

1
2
3
4
5
6
7
8

prevLogIndex: long  # 上一个 entry 的 index
prevLogTerm: long   # 上一个 entry 的 leader 任期
entries:
    - index: long
    - term: long
    - cmd: Command
leaderId: long      # 用于 Follower 识别发送 RPC 的 Leader
leaderCommit: long  # leader 已提交的 index, 用于通知 Follower 可以提交到哪个日志 index

日志复制

• 当 Leader 收到客户端请求后, 会生成一个 entry, 包含 < index, term, cmd >, 在将这个 entry 添加到自己的日志末尾后, 会向所有的节点发送 AppendEntries RPC 广播该 entry, 要求其他 Followers 复制这条 entry;
• 如果 Follower 接受该 entry, 则会将其添加到自己的日志后面, 同时返回给 Leader 已成功接受;
• 如果 Leader 收到了多数 Follower 的成功响应, Leader 会将这个 entry 应用到自己的状态机中, 随后将该 entry 置为 committed, 向客户端返回结果, 并将日志被 committed 的结果广播到整个集群, 以让各个 Follower 也将其应用到状态机;

状态快照

领导者选举

Candidate 发起选举的 RequestVote RPC 请求数据结构如下:

1
2
3
4

term: long
candidateId: long
lastLogIndex: long
lastLogTerm: long

随机 election timeout

每一个 Follower 会计算一个随机的 electionTimeout, 为了减少多个 Follower 同时成为 Candidate 的可能性, 从而提升 raft 选举的效率:

Leader 宕机重选

如下图所示, 当原 Leader B 宕机, A 率先触发 election timeout 变成 Candidate, 将任期 term 自增为 2, 并获得了 A 和 C 的多数派投票, 成功变为新的 Leader;
即使后续 B 重新上线, 当其检测到 A 的 term 大于自己时, 也会自动退变为 Follower;

选举资格限制

如 数据结构 所示, 每个 Candidate 发送 RequestVote RPC 时都会携带上一个 entry 的 < term, index > 信息, 当 Follower 收到投票信息时, 会比较自己与 Candidate 谁的日志更完整:

• 如果两个日志的 term 不同: 认为 term 大的更完整;
• 如果两个日志的 term 相同: 认为 index 大的更完整;

如果 Follower 发现自己的日志更加完整, 则拒绝投票给该 Candidate;
一般来说, 我们不保证旧 Leader 尚未 commit 的日志能顺利保留到下一任期中, 但要保证已经 commit 的日志不能丢失, 必须在下一任期中得到保留; 可惜, 仅仅依靠上述选举资格的限制规则并不能保证这一承诺;

Leader 交接的安全保证

在上述选举资格限制规则下, 如果我们允许新选举出的 Leader 直接提交上一任期的 entry, 就可能触发漏洞, 我们用一个例子来详细描述该问题;
假设一个 Raft 集群有 3 个节点:

1. term = 1: R1 是 Leader, 产生 entry < term=1, index=1 >, 尚未开始复制, 接着 R1 崩溃了;
2. term = 2: R3 当选新 Leader (由 R2、R3 投票产生), 产生 entry < term=2, index=1 >, 尚未开始复制, 也崩溃了;
3. term = 3: R1 恢复, 并重新当选新 Leader, 假设此刻 R1 复制了其 term = 1 任期的 entry < term=1, index=1 > 到 R2, 从而完成了多数派的复制, 于是直接提交该 entry, 然后 R1 再一次崩溃;
4. term = 4: R3 恢复, 并再次当选新 Leader (因为它 RequestVote 请求携带的 lastLogTerm = 2, 根据选举限制规则, R1 和 R2 均会认为 R3 比自己更完整), 假设此刻 R3 广播了其 term = 2 任期的 entry < term=2, index=1 >, 则 R1 和 R2 之前已经 commit 的 entry < term=1, index=1 > 将会被强制覆盖 (在 后续小节 将详细描述相关机制), 至此发生了已提交日志的丢失;

 
造成上述问题的根本原因是: 选举资格判定只能比较日志的新旧 (term 和 index), 而不关心日志是否已提交, 因此 Raft 必须禁止新 Leader 直接提交之前任期的日志;
为了解决该问题, Raft 要求新 Leader 必须先在当前任期开始时写入一条空命令日志 (no-op) 并提交它, 从而实现间接提交可能存在的之前任期的日志; 加上这个限制后, 我们再来推演一遍刚才的 case:

1. term = 1: R1 是 Leader, 产生 entry < term=1, index=1 >, 尚未开始复制, 接着 R1 崩溃了;
2. term = 2: R3 当选新 Leader (由 R2、R3 投票产生), 产生 entry < term=2, index=1, cmd=no-op >, 尚未开始复制, 也崩溃了;
3. term = 3: R1 恢复, 并重新当选新 Leader, R1 立即写入 entry < term=3, index=2, cmd=no-op > 并发送到 R2, Raft 的日志一致性机制 可以保证 R2 最终能接收到 < term=1, index=1 > 和 < term=3, index=2 > 两条日志, R1 完成多数派的复制后提交该 entry, 然后 R1 再一次崩溃;
4. term = 4: R3 恢复, 并尝试再次竞选 Leader, 可是它 RequestVote 请求携带的 lastLogTerm = 2, R1 和 R2 均认为其进度落后于自己, 不会投票给 R3, R3 将无法成为 Leader;

 
可见, 当任期开始立即写入一条 no-op 日志, 可以为新 Leader 建立起当前任期的权威, 向所有 Follower 宣告新王登基的事实; 在此之上 Raft 得以确保了已经 commit 的日志一定不会丢失: 当一个 Candidate 自身缺少已经在集群中 commit 的 entry 时, 一定不可能获得大多数选票, 从而不可能成为 Leader;

Leader 选举失败

当 raft 节点数为偶数时, 选举失败的可能性远大于奇数:

• 节点数为偶数: 只要有两个 Candidate 同时发起投票, 就有可能造成无人获得多数派, 导致本轮选举失败;
• 节点数为奇数: 至少要有三个 Candidate 同时发起投票才可能造成无人获得多数派;

但是 raft 随机 election timeout 的机制保证了 leader 选举的活性, 最终一定能通过有限的轮次选出 Leader;

强一致性保证

日志序列的强一致性

raft 的日志有两个基本性质:

1. 在两份日志里的两个 entry: 如果拥有相同的 index 和 term, 那么它们一定有相同的 cmd (即存储的命令是相同的);

• 第一个基本性质由 Leader 对 index 的唯一性保证: 在一个 term 内, 给定一个 index 最多创建一个 entry;

2. 在两份日志里的两个 entry: 如果拥有相同的 index 和 term, 那么它们各自前一个 entry 也一定相同;

• 第二个基本性质由 Leader AppendEntries RPC 请求的 数据结构 保证: Leader 会将新 entry 的前一条 entry 的 < prevLogIndex, prevLogTerm > 捎带进 AppendEntries RPC 中, 随后 Follower 的处理流程如下:

  • 检查 term: 如果 Leader 的任期小于自己的当前任期, 则拒绝该 RPC (并返回 Follower 自己的 term);
  • 检查 prevLogIndex 和 prevLogTerm: 如果 index - 1 != prevLogIndex || term - 1 != prevLogTerm, 则拒绝该 RPC;
  • 上两个检查通过: 将 entries 中的条目追加到自己的日志中;
  • 根据 leaderCommit 决定提交自己日志的 index, 并应用到状态机;

• Leader 强制对 Follower 作日志回退的场景:

  • Leader 给每一个 Follower 都维护了一个 nextIndex, 它表示 Leader 将要发送给该追随者的下一个 entry 的索引;
  • 当一个 Leader 刚开始自己的任期时, 它会将每个 Follower 的 nextIndex 初始化为它的最新的 entry index + 1;
  • Leader 根据 Follower 的 nextIndex 决定发送给目标 Follower 的 AppendEntries 请求内容;
  • 当 Follower 收到 Leader 的 AppendEntries 请求, 但检查 prevLogIndex 和 prevLogTerm 不通过而拒绝时:
    • Leader 会将 nextIndex 递减然后重试 AppendEntries RPC;
    • 最终 nextIndex 会达到一个 Leader 和 Follower 日志一致的地方, AppendEntries 将会返回成功, Follower 中冲突的 entries 会被移除, 并且补全所缺少的 Leader 的 entries;

注意: 被 Leader 强制回退的 Follower 日志一定是旧 Leader 尚未提交的 entry: 因为 Leader 选举限制规则已经强保证了被选出来的新 Leader 一定拥有完整的已提交日志, 如果某个 entry 在新 Leader 没有记录, 它一定是没提交的 entry;

网络分区下的强一致性

当 raft 节点数为奇数时, 可以保证当集群内出现两个分区时, 有大多数节点的分区可以正常运行 (另一个分区因无法形成多数派共识而不能提交日志);

• 当原 Leader 就在大多数节点的分区:
  • 大多数节点的分区继续运行, Leader 任期也不用变;
  • 另一个分区的节点将一直处于 Candidate 的状态, 无法选举出自己的 Leader;
• 当原 Leader 不在大多数节点的分区:
  • 大多数节点的分区将选出自己的 Leader, 任期 + 1, 并且能正常响应请求, 提交日志;
  • 另一个分区将无法提交日志;
    • 当网络分区消失后, 另一个分区的 Leader 将退变为 Follower, 分区内所有的节点将回退自己未提交的日志, 重新复制新 Leader 的日志;

成员变更

参考资料

• Raft: Understandable Distributed Consensus
• Raft: 易理解的分布式共识 (译)
• Raft: In Search of an Understandable Consensus Algorithm
• Raft: 探寻一种可理解的共识算法 (译)
• 为什么Raft算法是分布式系统的首选
• Protocol-03-Raft
• kubernetes 控制平面组件: etcd

在吸取了前辈 CMS 的经验教训之后, G1 的设计团队最终以一种脱胎换骨的姿态重磅推出了具有划时代意义的 Gabage First 收集器;
跳脱出 jvm 历史 GC 框架的局限性从 0 开始重新设计, G1 引入了 Region、Card、RSet 等多种创新性的数据结构, 极大地提升了年轻代及局部老年代收集的效率, 而这些设计思想也为后续的 ZGC、Shenandoah、Dragonwell Jade 等更先进的收集器所吸收采纳;

G1 的数据结构

G1 为了实现高效的垃圾收集, 使用了很多复杂的数据结构以记录并控制内存的使用情况:

Region

G1 将堆划分为一系列大小不等的内存区域, 称为 Region, 每个 Region 大小为 1 ~ 32M, 且必须是 2 的幂次方:

• 2 的幂次方大小可以确保堆区域的起始地址和结束地址对齐到特定的边界, 这有助于提高内存访问效率, 对齐后 CPU 可以更高效地访问内存, 减少缓存未命中和内存碎片;
• G1 内部使用位运算来管理堆区域, 2 的幂次方大小使得这些运算更高效;

G1 Heap Region

虽然 Eden、Survivor、Old 的概念和传统收集器类似, 但 G1 的内存管理是以 Region 为单位的, 这为更精细的内存回收提供了可能, 而不像传统 GC 只能以整个 Young 区 / Old 区为单位进行回收, 粒度很粗, 回收时长不容易控制;

G1 Heap Region

Card

G1 对 Region 内部的空间做了更进一步的精细管理:

• G1 将 Region 按照 512 Byte 为单位划分成多个 卡 (Card);
• G1 定义了一个全局字节数组 卡表 (Card Table), 其中的每个字节元素都唯一映射到 Region 中的一个 Card (稀疏索引);
  卡表的元素有两种值:
  • 0 (Clean Card): 表示该 Card 内的对象对其他 Region Card 的引用关系已经全部更新到了 RSet;
  • 1 (Dirty Card): 表示该 Card 内的对象对其他 Region 的引用关系发生了新的变更, 暂未同步到 RSet;
• 因为 Region 是连续分配的, 所以当给定任何一个对象的内存地址, 都可以快速定位到其在卡表中的索引 Card Index: $\frac{addr(instance) - addr(heap_start)}{512B}$;

G1 Card Table

需要注意的是: 卡表本身不是目的, G1 引入卡表是高效维护 Remember Set 的一种手段, 这一点在下一小节将会详细介绍;

Remember Set

记忆集 (Remember Set) 简称 RSet, 是一个哈希表结构:

• key: 引用本 Region 的其他 Region 的起始地址;
• value: 本 Region 中被 key 对应的 Region 引用的 Card Index 索引位置;

G1 RSet

每一个 Region 都有自己的 RSet, 于是当给定了一个 Card, 我们通过其对应的 RSet 可以非常高效地查询到哪些 Region 引用了目标 Card 中的对象;
理论上 RSet 应该记录任何跨 Region 的引用关系, 但实际上 G1 做了特定的优化, 并不会全部记录; 我们将 Region 按照代际划分, 那么 RSet 的引用关系可以分为四类:

1. 年轻代 Region 引用 年轻代 Region
2. 年轻代 Region 引用 年老代 Region
3. 年老代 Region 引用 年轻代 Region
4. 年老代 Region 引用 年老代 Region

其中 G1 不会记录年轻代 Region 对其他 Region Card 的引用关系, 也就是不会记录上述第 1、2 种类型:

1
2
3
4
5
6
7

void HeapRegionRemSet::add_reference(oop* from, HeapRegion* from_hr) {
  if (from_hr->is_young()) {
    // 如果引用来自年轻代，则不需要记录
    return;
  }
  _other_regions.add_reference(from, from_hr);
}

因为 RSet 的主要使用场景有两种 (后面章节会详细说明):

1. 在 Young GC 时, 跳过对 被老年代 Region 引用的 年轻代对象的扫描, 根据 RSet 直接执行快速标记, 从而降低整体标记阶段的开销;
2. 在 Mixed GC 时, 跳过对 被其他老年代 Region 引用的 需要收集的老年代对象的扫描, 根据 RSet 直接执行快速标记, 从而降低整体标记阶段的开销;

无论是什么类型的 GC, G1 本来就会扫描整个年轻代, 不存在需要通过 RSet 排除某些年轻代对象的场景, 额外记录年轻代 Region 对其他 Region Card 的引用关系反而会占用更多的内存;

RSet 的三级结构

RSet 并非永远都会记录 Region => Card Index 的关系, 因为 RSet 本质是一个哈希表, 当表中某个 slot 冲突严重, 就会发生退化:

RSet level

• 无退化场景 (最细粒度): regionId => cardIndex (数组);
• 无损压缩退化 (中等粒度): regionId => cardIndex (bitmap, 仅压缩, 信息不会丢失);
• 有损压缩退化 (粗粒度): regionId => 是否引用了当前 Region 中的对象 (布尔值);

G1 的收集过程

从宏观框架上看, G1 和 CMS 有着类似的思路, 都经历了几个经典过程: 初始标记、并发标记、最终标记、回收; 但在实现细节上, G1 相比 CMS 的差异就十分巨大了, 基于更精细的数据结构和引用关系追踪算法, G1 以空间换时间, 获得了比 CMS 更高的回收效率;
在展开 G1 的详细收集过程之前, 需要先讨论一下 G1 的写屏障实现思路:

G1 的写屏障

与 CMS 类似, 为了能与用户线程并发执行, G1 的收集也使用了三色标记法, 这意味着 G1 也必须要有自己的方案解决三色标记的漏标和多标问题;
与 CMS 使用 Incremental Update 聚焦于引用源头的写屏障不同, G1 垃圾收集器将写屏障拆分成了 写前屏障 (Pre-Write Barrier) 和写后屏障 (Post-Write Barrier), 它们的用途和触发时机不同, 共同协作实现了比 CMS 更加高效的并发垃圾回收;

写后屏障

G1 写后屏障的主要作用是维护 RSet (具体手段是通过标记 Card Table 再间接维护 RSet), 这是一个在整个 jvm 生命周期内都一直启用的特性;
当 jvm 执行到下面这个语句:

1
2

// 假设 oldObj 位于老年代 Region, newObj 位于年轻代 Region 
oldObj.field = newObj;

以上语句会改变 oldObj.field 的引用值, jvm 需要及时维护 newObj 对象所属 Region 的 RSet: 将 oldObj 对象所在的 Region 引用到 newObj 对象所属的 Card Index;
为了尽量减少 java 语句的执行开销, G1 将该逻辑分成了两个部分:

• 第一部分: 引用变更发生后, 先做标记, 而不做真正处理 (相对轻量的操作):

  • 先将 oldObj 所在的 Card 标记为 Dirty Card:
    
  • 再将该 Dirty Card 放入脏卡队列 (Dirty Card Queue, DCQ):
    • 优先加入当前线程的本地队列 (DirtyCardQueue);
    • 当本地队列已满, 将本地队列的脏卡刷入全局队列 (DirtyCardQueueSet, DCQS), 并申请新的本地缓存;

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

      void G1BarrierSet::write_ref_field_post(void* field, oop new_val) { if (new_val != NULL) { // 标记脏卡 CardTable::card_mark(field); // 将脏卡加入队列 G1ThreadLocalData::dirty_card_queue(Thread::current()).enqueue(field); } } void G1DirtyCardQueueSet::enqueue(void* card) { // 优先将脏卡加入本地队列 _queue->enqueue(card); if (_queue->is_full()) { // 如果本地队列已满，刷入全局队列 flush(); } }

• 第二部分: 使用指定线程消费 Dirty Card Queue (相对重量的操作):

  • G1 会根据全局队列 DCQS 的容量变化自适应决定脏卡消费处理的线程数量:
    
    • 当队列容量水位很低, 处于上图白色区域时: 没有线程会消费队列;
    • 当队列容量进入上图绿色区域时: G1 中专门用于消费 DCQS 的线程 Refinement 被激活, 可以用 -XX:G1ConcRefinementGreenZone=N 指定该阶段的线程数量;
    • 当队列容量进入上图黄色区域时: 说明产生 Dirty Card 的速度过快, G1 将激活更多的 Refinement 线程, 可以用 -XX:G1ConcRefinementYellowZone=N 指定该阶段的线程数量;
    • 当队列容量进入上图红色区域时: 队列即将溢出, 除了 Refinement 之外, 用户线程 (Mutator Thread) 也会一起参与消费 DCQS 处理脏卡;
      注意: 为了保障引用变更写屏障的高效和轻量, 用户线程参与处理脏卡, 依旧会先将脏卡放入队列, 后续再异步从队列中取出脏卡处理;
  • 当 G1 Refinement 线程取出一个 Dirty Card 的处理逻辑:
    • 先反向定位出该 Card 所在的 Region;
    • 再扫描该 Card 中的每一个对象, 找出每个对象所引用的其他对象, 根据被引用对象的地址定位出 Card Index;
    • 根据上面两个步骤, 便可以建立 Region => Card Index 的引用关系, 更新到 RSet;

写前屏障

G1 的写前屏障通过 SATB (Snapshot-At-The-Beginning) 实现, 这是一个只在 G1 开始执行垃圾收集才激活的特性; SATB 的发明者 Taiichi Yuasa 用两句话概括了该算法的核心思想:

1. Anything live at Initial Marking is considered live.
2. Anything allocated since Initial Marking is considered live.

也就是说, 当 G1 开始新的一轮收集时, 在开始时刻之前还活着的对象、以及开始时刻之后新创建的对象, G1 都认为是活着的, 不会被当前收集轮次给清理掉, 所以这个算法的名字很形象: 初始时刻快照;
虽然名字叫快照, 但是 SATB 并不是真正遍历去建立一个关于所有存活对象的物理快照 (如果那样就太耗费时间了, 而且还得 stw 才能准确构建不重不漏), 它以一种轻量级的方式对堆中的对象图建立了一个逻辑快照:

1. 在一个 GC 周期中, 如果创建了一个新对象, 那么不管它后续是否死掉, 本次 GC 都认为它存活;
2. 在一个 GC 周期中, 如果某个存活对象的引用从未被修改, 那么它最终一定能被三色标记法成功标记, 我们不需要额外干涉;
3. 在一个 GC 周期中, 一个之前就死掉的对象一定不会被三色标记法给标记到, 我们也不需要额外干涉;
4. 在一个 GC 周期中, 如果某个对象的引用被切断了 (比如从 obj.a = b 变成了 obj.a = null 或 obj.a = c, 则 obj 对 b 的引用被切断), 证明其在切断前 (收集初始时刻) 一定是存活的 (否则将不可达, 也就不会有被切断的机会), 那么需要主动将该对象 (b) 及其成员逐一标记;

 
要实现以上逻辑, 主要有两个关键点:

• 针对上文第 (1) 点: 我们需要一个高效的方案快速排除本轮 GC 中新建的对象, 将收集区域限定在旧对象里: 鉴于 G1 使用的是标记整理算法, 可以在给定空间里顺序分配对象, 那么在一个 region 中我们便可以引入几个指针:

  • BOTTOM: 指向当前 region 的起始地址;
  • TOP: 指向当前 region 分配下一个新对象的起始地址;
  • TAMS: Top-At-Mark-Start, 在标记开始时 TOP 指针指向的地址;

    

    G1 TAMS

    在新一轮 GC 启动, 进行初始标记时, 将 TOP 赋值给 TAMS, 那么在整个 GC 周期期间分配的新对象都落在 [TAMS, TOP) 之间, G1 直接对这个区间内的对象做隐式标记, 而只在 [BOTTOM, TAMS) 区间内应用三色标记, 就可以实现上文第 (1) 点;

• 针对上文第 (4) 点: 首先我们可以明确地发现, 只有 [BOTTOM, TAMS) 区间内的对象会遇到相关问题; 与写后屏障类似, 为了尽量减少 java 语句的执行开销, 以及尽可能快速执行并发标记, G1 将 “主动标记被切断引用的对象” 这个逻辑分成了两部分:

  1. 引用变更之前: 只将目标引用放入目标队列, 而不做真正处理 (相对轻量的操作):

     1 2 3 4 5 6 7 8

     // 用伪代码表示该逻辑 void pre_write_barrier(oop* field) { oop old_value = *field; if (old_value != null && is_marking_active()) { // 将旧引用加入 SATB 队列, 确保后续扫描 satb_queue.push(old_value); } }

  2. 在最终标记 (Remark) 阶段消费 SATB 队列, 取出旧引用并对其及其成员做真正的重新标记 (相对重量的操作);

 
总体来看, SATB 以极小的代价解决了漏标问题, 但也同时导致多标问题变得更严重: 因为某个对象的引用被切断了, 只要后续没有再被其他对象引用, 那这个对象确实就不可达了, 可当前轮次的 GC 并不会将其回收, 只能等下一次 GC 了;
其实如果将写前屏障与 RSet 结合起来, 就可以很大程度上缓解多标问题了: 只需在写前屏障第二阶段做 Remark 时:

1. 取出旧引用, 计算其所属 Region 和所属 Card Index;
2. 遍历 Region 对应的 RSet, 判断是否存在目标 Card Index 的引用关系:
   • 如有: 说明该对象很可能后续又被其他对象引用 (并不能 100% 肯定, 因为 RSet 的记录粒度最多只到 Card, 而一个 Card 内可能有多个对象), 本轮可以对其做标记;
   • 如没有: 说明该对象已不可达, 不应对其标记;

上述优化思路在某些资料中有描述, 但笔者并未找到 jvm 使用该方案的直接证据, 故将其作为额外补充记录下来;

Young GC 流程

Young GC 主要针对年轻代 Region, 包括 Eden 和 Survivor; 当所有 Eden 区使用率达到了最大阈值 (默认 60%) 或者 G1 计算出来的回收时间接近用户设定的最大暂停时间时, 会触发 Young GC; G1 的 Young GC 是全程 Stop-The-World 的, 且一次 Young GC 会回收全部年轻代 Region;
Young GC 的流程:

1. 初始标记 (Initial Mark): 从合并过 RSet 的 GC Roots 出发遍历标记所有存活的新生代对象
   • 部分线程直接从 GC Roots 开始扫描标记;
     • 注意: 需要过滤掉指向老年代对象的 GC Roots: 因为可以使用 RSet 更高效地获取被老年代引用的年轻代对象;
   • 部分线程排空 Dirty Card Queue: 把存量引用关系更新到 RSet, 再将 RSet 映射中记录的 Card Index 对应的对象作为 GC Roots 继续扫描标记;
2. 并发复制:
   • 对象年龄 < 15: 复制对象到 Survivor Region, 记录对象年龄 + 1;
   • 对象年龄 = 15: 晋升复制到 Old Region;
3. 清理垃圾;

Mixed GC 流程

Mixed GC 是 G1 特有的收集类型, 它会收集所有的 Young Region + 收益高的若干个 Old Region;

1
2
3

# 触发 全局并发标记 的已分配内存占整堆大小的比例, 简称 IHOP, 默认 45 (单位是 %)
# 关于已分配内存: jdk 8 之前是整体使用量; jdk 8 之后是老年代使用量
-XX:InitiatingHeapOccupancyPercent=n

当已分配的内存占内存总量比例超过了 IHOP 设置的阈值, 将会启动一轮 Global Concurrent Marking; 相比于 Young GC 的 stw, 全局并发标记因为涉及 Old Region, 其执行时间必然会远超 Young GC, 便不能再全程阻塞用户线程了, 对此 G1 使用了允许部分阶段与用户线程并发执行的策略, Global Concurrent Marking 的主要阶段和停顿类型如下:

当已分配内存达到 IHOP 阈值时, 仅仅是触发了 Global Concurrent Marking, 而非真正的 Mixed GC, Mixed GC 的触发时机还受到以下几个条件的限制:

1. -XX:G1HeapWastePercent: 允许垃圾大小占内存的最大比例, 当低于此值时不会触发 Mixed GC;
2. -XX:G1MixedGCLiveThresholdPercent: 老年代 Region 中的存活对象的占比, 只有在此参数之下才会被选入 Collection Set;
3. -XX:G1MixedGCCountTarget: 一次 Global Concurrent Marking 之后, 最多执行 Mixed GC 的次数;

我们可以设置一次 Mixed GC 需要回收的 Old Region 数量占比:

1
2

# 默认是 8: 意味着要在 8 次以内回收完所有的 Old Region
-XX:MixedGCCountTarget

极端场景: Full GC

当 Mixed GC 实在无法跟上程序分配内存的速度, 导致老年代填满无法继续进行 Mixed GC, 就会使用 Serial Old GC (后来被优化为多线程, 但相比 Mixed GC 依旧很慢) 来收集整个堆:

gc phase state transform

G1 实战

相关选项

通用选项:

1
2
3
4
5
6
7
8
9
10
11
12
13

# 开启 g1 收集
-XX:+UseG1GC

# 设置最大暂停时间 (默认 200 ms)
-XX:MaxGCPauseMillis=n

# 指定Region的内存大小, n 必须是 2 的幂次方, 其取值范围是从 1M 到 32M
-XX:G1HeapRegionSize=n

# 指定垃圾回收工作的线程数量, 8 核机器默认 5 个线程
-XX:ParallelGCThreads=n
# 默认值跟随 -XX:ParallelGCThread
-XX:ConcGCThreads=N

诊断选项:

1
2
3

# 开启并发标记阶段的时间消耗记录诊断
-XX:+UnlockDiagnosticVMOptions
-XX:+G1SummarizeConcMark

GC 线程

• STW 线程:

  • 线程名: GC Thread#{n}
  • 作用:
    • young gc;
    • mixed gc;
  • 设置方式:

    1	-XX:ParallelGCThreads=N

• 并发线程:

  • 线程名: G1 Conc#{n}
  • 作用:
    • concurrent mark;
    • 并发清理;
    • 并发引用处理;
  • 设置方式:

    1	-XX:ConcGCThreads=N

参考资料

• G1 Young GC时的to-space
• GC DURATION VS GC PAUSE DURATION
• G1 垃圾回收的survivor 0区貌似永远是0
• Garbage First Garbage Collector Tuning
• 译文-调整G1收集器窍门
• G1详解
• 极致八股文之JVM垃圾回收器G1&ZGC详解
• G1的SATB
• 图解G1垃圾回收器
• G1源码从写屏障到Rset全面解析
• 聊聊JVM G1（Garbage First）垃圾收集器
• SATB Desc
• G1原理—4.G1垃圾回收的过程之Young GC
• InitiatingHeapOccupancyPercent介绍

在 redis 2.8 之前, 基本可以认为 redis 不支持高可用部署模式, 因为仅靠 redis 主从同步机制, 当主服务器出现故障时, 并不支持自动将从服务器提升为主服务器, 而是需要运维人员手动介入; 很明显, 单独的 redis 主从模式不具备在生产环境部署的条件;
2013 年 9 发布的 redis 2.8 提供了一种哨兵模式, 终于在实质上解决了 redis 的高可用部署问题;

哨兵系统的构成

哨兵系统内由两部分组成 —— 哨兵节点和数据节点:

• 哨兵节点: 哨兵节点是特殊的 redis 节点, 不存储数据, 只用于管控数据节点, 一个或多个哨兵节点组成了一个哨兵集群;
• 数据节点: redis 主节点和从节点都是数据节点, 其存储真正的数据;

哨兵节点的作用:

• 监控: 哨兵会不断地检查主节点和从节点是否运作正常;
• 自动故障转移: 当主节点不能正常工作时, 哨兵会开始自动故障转移操作, 它将失效主节点的其中一个从节点提升为新的主节点, 并让其它从节点改为复制新的主节点;

redis 哨兵模式

节点的发现

启用哨兵模式, 只需要配置其监控的主数据库即可, 哨兵会自动发现所有复制该主节点的从节点:

1
2
3
4
5
6
7
8

# sentinel.conf

# sentinel monitor master-name ip redis-port quorum
# master-name: 要监控的主节点名称
# ip: 主节点 (master) 的地址
# redis-port: 主数据库的端口
# quorum: 触发客观下线的最低通过票数
sentinel monitor mymaster 127.0.0.1 6379 2

1
2

# 启动哨兵模式
> src/redis-sentinel sentinel.conf

哨兵启动后会与要监控的主节点建立两条连接:

哨兵与主节点的连接

其中 _sentinel__:hello 频道是一个特殊的发布/订阅频道, 用于哨兵实例之间的通信;
 
和数据节点建立连接完成后, 哨兵会使用 连接2 发送如下命令:

• 每 10 秒钟哨兵会向数据节点发送 INFO 命令; 数据节点响应 INFO 命令并返回当前节点的相关信息 (运行 id、从节点信息等) 从而实现新节点的自动发现;
• 每 2 秒钟哨兵会向主节点的 _sentinel_:hello 频道发布自己的消息, 以与同样监控该节点的其他哨兵分享自己的信息;

  

  哨兵集群的发现

  发布内容为: <哨兵的地址>, <哨兵的端口>, <哨兵的运行ID>, <哨兵的配置版本>,
  <主数据库的名字>, <主数据库的地址>, <主数据库的端口>, <主数据库的配置版本>;
• 每 1 秒钟哨兵会向主数据、从数据库和其他哨兵节点发送 PING 命令;

故障转移流程

通过如下配置 PING 命令健康检查的超时时间:

1
2
3
4
5
6

# sentinel.conf

# 每隔 1s 发送一次 PING 命令 (因为配置值超过 1s), 当超过 6s 没回复, 认为节点主观下线
sentinel down-after-milliseconds mymaster 6000
# 每隔 600 ms 发送一次 PING 命令, 当超过 600 ms 没回复, 认为节点主观下线
sentinel down-after-milliseconds mymaster 600

具体流程如下:

1. 每个哨兵节点每隔指定时间会向主节点、从节点及其它哨兵节点发送一次 PING 命令做一次心跳检测; 如果主节点在指定时间内不回复或者是回复一个错误消息, 那么这个哨兵就会认为这个主节点已主观下线 (Subjectively Down, SDOWN);
2. 如果一个主节点被标记为 SDOWN, 则正在监视这个主节点的所有哨兵节点 要以每秒一次的频率确认该主节点的确进入了 SDOWN 状态;
3. 当超过指定数量 (sentinel.conf 配置的 quorum) 的哨兵节点认为某主节点主观下线了, 这个节点就被认为已客观下线 (Objectively Down, ODOWN);
4. 哨兵节点会通过 Raft 算法 共同选举出一个哨兵节点为 leader, 以负责处理主节点的故障转移和通知;
5. 由 leader 哨兵节点负责真正的故障转移:
   • 过滤掉不健康的 (已下线的), 没有回复哨兵 PING 命令的从节点;
   • 选择配置文件中从节点优先级配置最高的 (redis.conf 中的 replica-priority, 默认值为 100);
   • 若优先级相同, 选择复制偏移量最大的从节点, 也就是复制最完整的从节点;
   • 若复制偏移量依然相同, 则直接选择 runID 最大的从节点;
   • 将选定的从节点提升为新的主节点, 让其它从节点指向新的主节点;
   • 若原主节点恢复也变成从节点, 并指向新的主节点;
   • 通知客户端主节点已经更换;

哨兵自动转移故障

基于哨兵自研 redis 集群

redis 哨兵模式虽然解决了 redis 高可用部署的问题, 但是没有解决单点瓶颈横向扩展的问题, 这对于规模扩张十分迅速的互联网行业来说, 也是不可接受的;
redis 3.0 推出原生集群模式是在 2015 年, 而那在之前, 互联网公司想要实现一个 redis 集群就只能自己动手了, 其实我们完全可以在哨兵模式的基础上, 通过旁路数据控制、客户端能力增强, 扩展出可横向数据切分、可动态扩缩容的 redis 集群;
概括来说, 一个 redis 集群的核心能力只有几点:

1. 多副本、数据分区冗余能力;
2. 副本故障自动转移能力;
3. 横向切分, 多数据分片能力;
4. 可扩缩容、数据迁移能力;

其中, 第 1 点由 redis 原生的主从复制能力解决; 第 2 点由 redis 原生的哨兵模式解决; 要实现一个真正意义上的 redis 集群, 就只需要自主实现第 3、4 两点即可;
我们以去哪儿网 (qunar.com) 的自研 redis 集群为例介绍:

qunar redis 集群架构

去哪儿网是国内较早在生产环境大规模部署 redis 实例的互联网公司之一, 由于历史早期 redis 不支持原生集群模式, 去哪儿网只能基于仅具备主从/哨兵能力的 redis 版本自研了一套 redis 集群:

1. 实现一个旁路的配置中心, 存储 redis 集群内各个实例的信息, 包括: 实例的 ip/port、slot 的 start/end 偏移等;

   

   redis 集群配置信息

2. 实现 redis 客户端的路由能力: 3.0 之前的 redis 版本不感知什么叫做分片, 没有路由的概念, 无法像 3.0 之后的版本针对不属于当前实例的 key 返回 MOVED 错误, 必须由客户端自己去感知分片实现路由, 需要能够从配置中心读取集群配置, 当查询具体的 key 时, 通过协商一致的 hash 算法计算 key 对应的 slot, 再继续定位到 slot 所在的实例;
3. 实现配置的及时更新:
   • 增强哨兵集群的配置变更能力, 当主节点故障实施自动切换的同时 (也适用于扩缩容的场景):
     • 更新配置中心, 替换实例的 ip/port;
     • 将最新集群信息写入 zookeeper 对应节点, 方便客户端及时感知集群实例变更, 拉取最新配置;
   • 增强客户端的配置感知能力:
     • 定时从配置中心获取最新配置, 当配置变更, 重新建连;
     • 监听目标集群对应的 zookeeper 节点, 当收到节点变更通知, 及时去配置中心获取最新配置, 重新建连;

扩缩容的实现

动态路由感知不是 qunar 自研 redis 集群最复杂的地方, 扩缩容才是, 因为扩缩容涉及数据的 reshard & migrate; 为了避免影响线上请求, qunar 采用了新建一个扩缩容后的独立目标集群, 然后将路由切过去的解决方案, 该方案的核心就是实现一个主从复制的双向代理中间件:

qunar redis 集群扩缩容

1. 作为源集群的从库, 同步源集群的数据;
2. 作为目的集群的主库, 实现数据迁移到目的集群;
3. 根据目的端集群的拓扑信息, 按照客户端分片算法, 将数据分发到目的端集群的各个分片;

当源目两库完成全量同步, 进入增量同步的阶段, 进行数据校验, 若数据一致, 实行配置切换, 即完成了扩缩容操作;

参考资料

• Redis集群方案：主从、哨兵和Cluster
• redis哨兵和集群
• 深度好文：Redis哨兵集群
• Redis哨兵模式详解
• 去哪儿网 Redis 自动化运维体系

虚拟线程作为 jdk 19+ 最重要的特性之一, 足以对所有 java 开发者构成巨大的吸引力; 我们即便无法很快在生产环境中升级到最新版本的 jdk, 但也应该足够重视, 尽早学习, 跟上时代节奏, 避免被职场淘汰;

虚拟线程相关的 jvm 配置参数

1
2
3
4
5
6
7
8
9

# ForkJoinPool 默认并发度 / 平台线程 (物理 OS 线程) 数
-Djdk.virtualThreadScheduler.parallelism=128
# 调度器的最大并发度
-Djdk.virtualThreadScheduler.maxPoolSize=2048
# 最少运行的线程数
-Djdk.virtualThreadScheduler.minRunnable=32

# 追踪被 pin 住的虚拟线程: full 表示全量采样 / short 表示部分采样
-Djdk.tracePinnedThreads=full/short

虚拟线程的使用

方式一: 直接构造 ThreadFactory 并调用其 newThread 方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public static final ThreadFactory newVirtualThreadFactory(final String prefix) {
    return Thread.ofVirtual()
        .name(prefix + "-")
        .uncaughtExceptionHandler((t, e) -> {
            log.error("Uncaught exception, thread:[{}]", t, e);
        })
        .factory();
}

final ThreadFactory vTreadFactory = newVirtualThreadFactory("myThreadPrefix-");
final Thread vThread = vThreadFactory.newThread(() -> {......});
vThread.start();
if (vThread.getState() == Thread.State.TERMINATED) {
    throw new IllegalStateException("thread is terminated");
}

方式二: 使用 Executors 封装的工具方法

1
2
3
4

// 默认无线程名, 为空字符串
var executor = Executors.newVirtualThreadPerTaskExecutor();
// 指定线程名前缀及起始计数, 线程名: myThreadPrefix-${i}
var executor = Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("myThreadPrefix-", 1).factory());

虚拟线程的火焰图

VT flame graph

使用虚拟线程的注意事项

池化问题

传统的 java 线程与 OS 线程是一一对应的, 创建代价较为昂贵, 在 Thread-Per-Request 编程模式下, 请求数远超 OS 所支持的最大线程数, 因此我们通常会使用线程池 (ThreadPoolExecutor) 来避免不必要的线程创建和销毁; 与此同时, ThreadPoolExecutor 内部存在较为复杂的状态管理, 并引入阻塞队列 workQueue, 在特定状态下引导 command 排队挂起/唤醒, 这是管理池化资源不得不引入的复杂性;
而虚拟线程本质上只是一个轻量级的 java 对象, 创建和回收的成本很低, 在这种情况下如果使用复杂的 ThreadPoolExecutor 管理 virtual thread, 显得有些小题大做, 因此 java 官方不推荐对虚拟线程做池化缓存;
但虚拟线程作为 java 对象毕竟还是占用有限的内存资源的, 不可能无限创建, 对此 java 官方推荐直接使用 java.util.concurrent.Semaphore (信号量) 来限制 virtual thread 的总量; 同 ThreadPoolExecutor 中的 Worker 类似, Semaphore 也是基于 AbstractQueuedSynchronizer 的同步器, 但 Semaphore 只关心资源总量的限制, 没有 ThreadPoolExecutor 其他的复杂管理逻辑, 使用效率更高;

FJP 虚拟线程回收速度

在 jdk 21 下, 当使用 virtual thread 的应用流量卸掉后, ForkJoinPool 线程回缩得很慢, 每次 keepAlive 时间后只缩小 1 个 virtual thread, 官方回复 jdk 22 修复: JDK-8319662;

pinning 问题

受限于操作系统或 virtual thread 的实现, 有一些阻塞操作是无法被 carrier 线程卸载的, 即虚拟线程会被禁锢在了 carrier 线程上, 致使 carrier 线程无法调度其他虚拟线程, 我们应当尽可能避免这种情况的发生, 例如:

• synchronized 代码块内的阻塞操作, 比如 synchronized 里去调用 Thread#sleep;

  • 典型 bad case: guava cache 使用了 synchronized, 所以不能在使用了 guava cache 的业务应用里直接使用 virtual thread, 需要先替换为 caffeine cache;
  • java 官方对虚拟线程未来支持 synchronized 的态度: 不够重视, 预计很难在 jdk 23 之前支持;
    

• Object#wait() 方法的执行;

• native 方法的执行;

• 外部函数的执行;

• 大部分对文件系统的操作;

• 类加载 (致命弱点)

  • dd

    1 2 3

    -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1 -Djdk.virtualThreadScheduler.minRunnable=1

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

  public class VTTest { static final CountDownLatch countDownLatch = new CountDownLatch(1); static final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor(); public static void main(String[] args) throws IOException { executor.execute(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { throw new RuntimeException(e); } countDownLatch.countDown(); }); executor.execute(InnerSleepClass::hello); System.in.read(); } private static class InnerSleepClass { static { try { countDownLatch.await(); System.out.println("exit count down."); } catch (InterruptedException e) { throw new RuntimeException(e); } } static void hello() { System.out.println("hello"); } } }

当 OS 线程因为这些特殊的阻塞操作无法卸载虚拟线程时, 调度器 (ForkJoinPool) 会临时增大并发度, 可通过该选项来调整最大并发度:

1

-Djdk.virtualThreadScheduler.maxPoolSize=2048

JDK 也提供了工具帮助我们发现这些无法被卸载的阻塞操作:

1
2
3

# full 表示全量采样
# short 表示部分采样
-Djdk.tracePinnedThreads=full/short

采样举例:

1
2
3
4
5
6
7
8
9
10

Thread[#22,ForkJoinPool-1-worker-1,5,CarrierThreads]
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:185)
    java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
    java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:634)
    java.base/java.lang.VirtualThread.sleepNanos(VirtualThread.java:806)
    java.base/java.lang.Thread.sleep(Thread.java:594)
    org.example.Main.lambda$executeTest$0(Main.java:35) <== monitors:1
    java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
    java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
    java.base/java.lang.VirtualThread.run(VirtualThread.java:314)

参考链接

• ForkJoinPool trims worker threads too slowly

从一部小小的美国航母兴衰史, 可以影射出美国造船业的兴衰史, 甚至由此瞥见了整个美国工业的兴衰史;
从上世纪尼米茨级的一骑绝尘, 到如今福特级的拉胯与不堪用, 美国海军已经走到了一个历史极点, 军事霸权的基石摇摇欲坠, 待后续尼米茨的退役潮来临, 福特级将何去何从?

二战后的美国航母

弦号前缀释义:

• CV (航空母舰): Carrier Vessel
• CVA (攻击型航空母舰): Carrier Vessel Attack (已弃用)
• CVS (反潜型航空母舰): Carrier Vessel Anti-Submarine (已弃用)
• CVN (核动力航空母舰): Carrier Vessel Nuclear (CVA / CVS 并轨, 后续统一为 CVN)

下一代航母: 福特级

福特级航母的第一艘 (CVN-78) 于 2009 年开工建造, 2017 年下水;
CVN-78 的基本参数:

• 长度为 333 米, 最大宽度为 78 米;
• 使用了 23 种全新的技术, 但步子迈得太大, 新技术不稳定导致故障不断, 无法形成有效战斗力;

电磁弹射问题

福特级的电磁弹射使用高压交流系统, 优点是能量密度大, 功率高, 缺点是稳定性不够, 故障率高;
福特级的电磁弹射的设计平均故障周期指标是 4100 次弹射, 实际故障周期为:

• 2017 ~ 2020 年: 181 次弹射;
• 2021 年: 380 次弹射;
• 2022 年之后: 400+ 次弹射;

虽然每年都在优化与提升, 但还是远远达不到军方标准;

储能/转换系统

福特级航母的每套弹射器都共用 3 套总容量 720 兆焦的飞轮储能系统, 整个供电与储能系统用的是中压交流供电系统; 飞轮储能可以发出交流电, 但结构太复杂, 机械能转换能量损耗大;
福特级电磁弹射系统的部分问题也来自于这个中压交流系统, 问题集中在储能和转换系统上, 而四套弹射器共用整个储能和转换系统, 导致无法实现单台电磁弹射器的电气隔离, 这就是福特级电磁弹射器出故障时必须四套同时停工才能维修的原因;
美军打算在后续的电弹系统中将储能子系统换成超级电容; 虽然超级电容储能比较简单, 但是电容储存的是直流电, 放电时需要转换交流电, 这样整个体系中就需要一道 AC-DC-AC (充电时交流转直流, 放电时直流转交流) 的转换, 依旧麻烦无比; 因为基础技术选型的失误, 现在福特级已经处于一种进退失据的境地, 尤其在我国的福建号进展迅速的前提下, 重新回炉设计时间完全来不及, 在现有基础上硬着头皮改也没法从根本上解决问题;
与之对应的是, 我国福建号的技术路线是马伟明院士提出的中压直流系统, 全链路的直流体系完美避免了交流系统的复杂性;

弹射器的数量

福特级沿用了前型尼米茨级的 4 条弹射器;
尼米茨级使用四条弹射器的原因是蒸汽弹射器不能持续弹射, 每次弹射存在 2 吨的蒸汽损耗, 以美军航母通用的 C13B2 型蒸汽弹射器为例, 其最多能在 30 分钟内进行 18 次快速弹射, 此后弹射器的效率会降低, 每隔 5 分钟才能弹射一架飞机, 期间需要补充蒸汽; 所以一般两个一组, 一条弹射另一条储压, 交替弹射;

中美航母弹射器布局对比

福特级的电磁弹射系统在 4 条弹射器之间共用三个储能飞轮, 各套弹射器之间没有实现电气隔离, 并不适用于蒸汽弹射交替弹射的场景, 达不到一条弹射另一条储能的效果; 而左舷多出来的第四条弹射器过多侵入了着舰区, 也无法实现舰载机着舰时同时使用第四条弹射器;

体积超标

因为散热控制以及电磁屏蔽, 因为弹射过程中多个结构都需要快速散热, 比如电机工作时的高温以及导轨加速产生的巨大热量, 还有电机工作时极端电磁场, 相当于一枚小型 EMP 爆炸, 需要将其屏蔽在甲板下, 避免其影响战斗机航电系统;
福特号航母在增加了这些散热结构和电磁屏蔽系统以及储能与转换与控制系统后, 电磁弹射系统的体积居然达到了 1061.4 立方米, 和蒸汽弹射的 1100 立方米相差无几, 而重量则超过了 630 吨, 已经高于蒸汽弹射;

阻拦索问题

福特级使用了先进的电磁阻拦索 (AAG), 以液压涡轮来提供阻拦力, 通过软件实时分析拉力传感器反馈的力度数据, 智能控制电动机带动拦阻索, 实现阻拦过程的负载均衡, 从而解决以往通过巨型液压缸、活塞和加压空气等机械结构阻拦 “力度过猛” 导致对舰载机结构和拦截钢缆产生显著损耗的问题;
福特级电磁阻拦索的设计评估故障周期指标是 16500 次阻拦, 实际故障周期为 41 次;

电磁阻拦索内部结构

升降机问题

福特级的 11 个弹药升降机使用了先进的电磁升降机, 而是依靠光滑的接触面和电磁力, 让活动台面吸附到提升上下轨道的边框上, 进行弹药的运输, 不再需要电缆和钢索等过多的笨重设备;
福特级电磁升降机的设计平均故障周期指标是 932 小时, 实际故障周期为 218 小时, 且 11 个升降机只有 8 个验收通过;

电磁升降机内部结构

参考链接

• 福特号首次战斗部署，暴露美国制造的两大顽疾，给福建舰提了个醒
• 福特级航母有哪些革命性的技术应用，为什么能称「世界最强」
• 除了电磁弹射器之外，福建舰还会装备电磁拦阻系统吗
• 美国最新福特号航母再曝漏洞：AAG先进拦阻系统质量不过关
• 到底是3台弹射器还是4台弹射器？几个升降机
• 003航母：电磁弹射起飞一架飞机到底要消耗多少电能

在 LSM 树 (Log-Structured Merge-Tree) 的设计中，读放大 (Read Amplification)、写放大 (Write Amplification) 和空间放大 (Space Amplification) 形成了一个类似 不可能三角 的权衡关系, 优化其中任意两个通常会恶化第三个; 这一现象类似于存储系统中的 RUM Conjecture (Read、Update、Memory overhead 不可能同时最优);

LSM-Tree 的放大问题

读放大

完成一次查询需要读取的数据量比实际所需数据多;
原因：

• 数据可能分布在多个SSTable中（MemTable + 多级SSTable），查询时需要检查多个文件。
• 即使使用Bloom Filter减少无效IO，范围查询仍可能需要合并多个SSTable的结果。

优化方法：

• 增加Bloom Filter的精度，减少无效磁盘访问。
• 使用分层Compaction（如Leveled Compaction），减少每层SSTable的重叠范围。

写放大

实际写入磁盘的数据量比用户写入的数据量大;
原因：LSM树通过后台 Compaction 合并 SSTable, 导致数据被反复重写 (例如: LevelDB 的 Leveled Compaction 可能产生 10 倍以上的写放大);

优化方法：

• 采用 Tiered Compaction (类似 Cassandra 的 STCS), 减少 Compaction 频率;
• 使用增量压缩（如ZSTD）减少写入数据量。

空间放大

存储的冗余数据比实际有效数据多;
原因：

• 由于Compaction不是实时进行，同一份数据可能在多个SSTable中存在（未合并前）。
• 删除操作只是标记（Tombstone），直到Compaction才真正清理。

优化方法：

• 更激进的Compaction策略（如Size-Tiered → Leveled）。
• 尽早合并Tombstone，减少无效数据占用空间。

LSM-Tree 的不可能三角

现实中的权衡案例

• RocksDB（Leveled Compaction）：优化读放大和空间放大，但写放大较高（适合读多场景）。
• Cassandra（Size-Tiered Compaction, STCS）：优化写放大，但读放大和空间放大较高（适合写多场景）。
• WiscKey（KV分离）：优化写放大和空间放大，但读放大增加（需额外查询Value日志）。

如何根据业务场景选择策略

优化

LSM树的 “三个放大” 问题确实是一个不可能三角，但通过合理的Compaction策略、索引优化（Bloom Filter、SSTable索引）和存储分层（Hot/Cold Tiering），可以在特定业务场景下取得较好的平衡。现代LSM引擎（如RocksDB）通过动态调整 Compaction 策略、使用 KV 分离（如WiscKey）等技术，正在不断逼近这个三角的更优解;

日志结构合并树是一种巧妙的数据结构, 它是一种妥协的艺术: 它在关注写性能的同时也尽量照顾到了读性能, 适用于写多读少、写多读中等的场景, 甚至在一些数据库产品中直接将其作为核心存储引擎 (如 TiDB -> TiKV 基于 RocksDB);
因此很有必要学习一下 LSM-Tree 的原理;

B+ 树 (如数据库索引) 和 log append 型操作 (如数据库 WAL 日志) 是数据读写效率的两个极端; 磁盘读写分为随机读写和顺序读写，一般来说随机读写的效率要低于顺序读写。

• B+ 树解决的是磁盘随机读慢的问题, 但随机写无法保证效率, 因为写入数据时涉及到树的重构: 读效率高而写效率差;
• log append 型文件操作解决的是磁盘随机写慢的问题, 但读时需要遍历整个文件: 写效率高而读效率差;

为了在排序和 log append 型文件操作之间做个折中, 就引入了 Log-Structed Merge Tree 模型, LSM Tree 既有日志型的文件操作提升写效率, 又在每个 sstable 中排序保证了查询效率;

LSM-Tree 的数据结构

WAL

MemTable

SST (Sorted String Table)

LSM-Tree 的压缩

在 LSM-Tree 中，压缩算法主要有两种策略：Tiering 和 Leveling, 它们的区别主要体现在如何组织和管理不同层级的数据，以及如何执行合并操作;

Tiering

Tiering 策略允许每一层（Level）包含多个 SSTable，并且每一层的 SSTable 之间可以有重叠的键范围。压缩操作主要发生在同一层内，将多个小的 SSTable 合并成一个更大的 SSTable，然后将其推送到下一层。

特点:

• 写放大较低：由于每一层可以包含多个 SSTable，压缩操作不需要频繁地将数据向下层移动，因此写放大（Write Amplification）较低。
• 读放大较高：由于每一层的 SSTable 之间可能有重叠的键范围，查询时可能需要检查多个 SSTable，导致读放大（Read Amplification）较高。
• 空间放大较高：每一层可能包含多个 SSTable，且这些 SSTable 之间可能有重复的数据，因此空间放大（Space Amplification）较高。

适用场景:

• Tiering 适合写密集型工作负载，尤其是对写性能要求较高的场景。

Leveling

Leveling 策略要求每一层（Level）只能包含一个 SSTable，并且每一层的 SSTable 的键范围不重叠。压缩操作主要发生在相邻的两层之间，将上层的 SSTable 与下层的 SSTable 合并，生成一个新的 SSTable 并推送到下层。

特点:

• 写放大较高：由于每一层只能包含一个 SSTable，压缩操作需要频繁地将数据向下层移动，导致写放大较高。
• 读放大较低：由于每一层的 SSTable 之间没有重叠的键范围，查询时通常只需要检查一个 SSTable，因此读放大较低。
• 空间放大较低：每一层只有一个 SSTable，且键范围不重叠，因此空间放大较低。

适用场景:

• Leveling 适合读密集型工作负载，尤其是对读性能要求较高的场景。

策略对比

混合策略:
在实际应用中，有些系统会采用 混合策略，结合 Tiering 和 Leveling 的优点。例如，在较低的层级使用 Tiering 以减少写放大，而在较高的层级使用 Leveling 以降低读放大和空间放大。

通过选择合适的压缩策略，LSM-Tree 可以在不同的工作负载下实现性能的优化。

参考资料

• RocksDB的一些基本概念及简单应用

Leslie Lamport 于 1990 年提出的 经典 Paxos 是分布式共识算法的开山鼻祖, Google Chubby 的作者 Mike Burrows 就曾说过: 「这个世界上只有一种一致性算法, 那就是 Paxos」, 其他所有的一致性算法, 本质上都是对 Paxos 在实现层面的变体、优化或扩展;
因此 Paxos 算法是分布式理论入门的第一块基石, 欲涉足该领域, 就必须将其完全地、彻底地研究清楚;

分布式系统

我们为什么需要分布式系统?
因为物理硬件是不可靠的, 磁盘损坏、服务器宕机、网络丢包等各种问题都会造成传统单机服务的不可用, 所以我们必须使用分区冗余容错的方式 (多副本) 来对抗物理硬件的不可靠, 也就是说, 我们只有使用分布式系统, 才能架设起高可用、高可靠的业务服务;
但要让一群原本毫无关联的机器实现协调统一的默契合作却绝非易事, 我们设计出的分布式算法至少要满足以下能力:

• 高可靠性: 当客户端写入数据, 服务端返回成功, 必须保证客户端下次读取时一定能查询到, 不能丢失;
• 高可用性: 当分布式系统内的若干台机器宕机时, 系统整体依然能够对外正常提供服务;
• 强一致性: 整个系统必须对外保持一致的状态视图, 即同一时刻下客户端无论怎么请求读, 总能获取到相同的值;

有一个值得注意的点是: 并不是说, 凡存在多台机器分区部署的系统都叫做分布式系统; 比如我们绝大部分的业务应用, 会在很多台机器上部署相同的代码, 通过流量接入层的反向代理与负载均衡, 对外提供统一的服务, 这些机器之间没有任何交互, 甚至感知不到其他机器的存在, 这显然不能算分布式系统, 只能算是分布式集群;
区别分布式系统和分布式集群最关键的一点是有无状态:

• 当提供的是有状态服务 (比如存储系统), 需要多副本和跨机器复制, 需要使用共识算法来协调各机器间的状态同步时, 叫做分布式系统;
• 当提供的是无状态服务 (如普通的业务服务), 无需亲自实现状态存储的逻辑 (通常是代理给了下游的分布式系统去实现, 比如数据库), 叫做分布式集群;

Paxos 之前的分布式算法

在 Paxos 诞生之前, 其实已经有很多方案尝试去解决分布式系统的难题, 但他们都有自己的局限性和缺陷, 无法全部解决上述三个问题;

主从异步复制

主从异步复制是最简单的策略, 但存在一个最基本的问题: 客户端请求写入数据, 收到服务端的响应成功, 离数据真正安全 (数据复制到全部的机器上) 在时间上有一个空隙, 如果接收请求的 master 在响应成功后立刻宕机, 数据就会丢失, 因此主从异步复制不可靠;

主从异步复制

主从同步复制

跟主从异步复制相比, 主从同步复制提供了完整的可靠性: 直到数据真的安全的复制到全部的机器上之后, master 才会向客户端响应成功; 但主从同步复制有个致命的缺点: 整个系统中有任何一个机器宕机, 写入就进行不下去了, 相当于系统的可用性随着副本数量的增加而指数性降低, 因此主从同步复制不具有高可用性;

主从同步复制

主从半同步复制

如果在主从同步复制和主从异步复制之间做一个折中, 要求 master 在应答客户端之前必须把数据复制到足够多的机器上, 但不需要是全部, 这就是主从半同步复制; 这样副本数够多可以提供比较高的可靠性, 同时在 1 台机器宕机时也不会让整个系统 hang 住;
这种方案似乎同时解决了高可靠和高可用的问题, 但是主从半同步复制依然无法解决一种情况,例如:

• 数据 a 复制到了 slave1, 但没有复制到 slave2;
• 数据 b 复制到了 slave2, 但没有复制到 slave1;

这时如果 master 挂掉了需要从某个 slave 恢复出数据, 任何一个 slave 都不能提供完整的数据 a 和 b, 因此主从半同步复制不完全可靠;

主从半同步复制

多数派读写

为了解决半同步复制中数据不一致的问题, 可以将这个复制策略稍做改进: 多数派 (Quorum) 读写, 每条数据必须写入到半数以上的机器才能返回成功, 每次读取数据也都必须从半数以上的机器获取, 以确认数据是否存在;
这种方案已经同时解决了可靠性和可用性, 但可惜它解决不了一致性的问题, 例如:

• 第一次更新向 node1 和 node2 写入了 a = x;
• 第二次更新向 node2 和 node3 写入了 a = y;

那么此时客户端分别从 node1、node2 读取 a, 将读出两个不同的值, 从而无法确定真正的结果, 因此多数派读写不具有强一致性;

多数派读写

带版本的多数派读写

针对上述多数派读写的一致性问题, 可以给每次请求写入带上一个全局单调递增的 version, 读取的过程中优先采纳版本更高的值; 只不过这种方式依然有缺陷: 当客户端没有完成一次完整的多数派写时, 比如:

• 第一次更新向 node1 和 node2 写入了 a = x (version=1);
• 第二次更新只向 node3 写入了 a = y (version=2) 后就宕机或后续逻辑执行延迟;

若另一个客户端此时试图读取 a 时:

• 当从 node1 和 node2 读取时, 得到的结果为 x;
• 当从 node2 和 node3 读取时, 得到的结果为 y;

因为这种方式不能做到事务性更新 (没有原子性、没有隔离性), 因此带版本的多数派读写仍不具备严谨的强一致性;

带版本的多数派读写

Paxos 的实现

Paxos 是多数派读写的进一步升级, 其通过 2 次原本并不严谨的带版本多数派读写, 实现了严谨的强一致性共识算法;

Phase-1: Prepare

phase-1 的 Proposer 请求与 Acceptor 响应:

1
2
3
4
5
6
7
8
9
10
11

> request (Proposer):
    rnd: int

> response (Acceptor):
    if (rnd < last_rnd):
        return fail // 中断拒绝
    return {
        last_rnd: int
        last_v: "xxx"
        last_vrnd: int
    }

Proposer 对 phase-1 中 Acceptor 响应的处理:

1
2
3
4
5
6
7
8
9
10
11
12

> response (Acceptor):
    last_rnd: int
    last_v: "xxx"
    last_vrnd: int
    
> resp_process (Proposer):
    // 所有 acceptor 应答的 last_v / last_vrnd 都是空: 用自己的 v / vrnd
    if (last_v == nil && last_vrnd == nil):
        use(v, vrnd)
    // 从所有 acceptor 应答中选择 last_vrnd 最大的 last_v 作为 phase-2 要写入的值, 但 vrnd 依旧用自己的
    v_with_biggest_rnd = chooseBiggestRndV(last_v, last_vrnd)
    use(v_with_biggest_rnd, vrnd)

注意: 如果 Proposer 收到了某个应答包含被写入的 last_v 和 last_vrnd, 这时当前 Proposer 必须假设有其他客户端 (Other Proposer) 正在运行, 虽然不知道对方是否已经成功结束, 但任何已经写入的值都不能被修改, 所以当前 Proposer 必须保持原有的值: 将看到的最大 last_vrnd 对应的 last_v 作为下一阶段将要写入的值;

Phase-2: Commit

phase-2 的 Proposer 请求与 Acceptor 响应:

1
2
3
4
5
6
7
8

request (Proposer):
    v: "xxx"
    rnd: int

reponse (Acceptor):
    if (rnd < last_rnd):
        return fail // 中断拒绝
    record (v, vrnd)

Acceptor 通过比较 phase-2 请求中的 rnd 和自己本地记录的 last_rnd, 来确定当前请求的 Proposer 是否还有权写入:

• 当 rnd == last_rnd: 这次写入是被允许的, Acceptor 将 v 写入本地, 并将 phase-2 请求中的 rnd 记录到本地的 vrnd 中;
• 当 rnd < last_rnd: 拒绝返回失败;
• 不可能存在 rnd > last_rnd 的情况: 因为 phase-1 保证了 Proposer 的 rnd 一定曾被 Acceptor 记录下来过;

Paxos 的完备性证明

Paxos 的安全性

Paxos 的活性

Paxos 的变种

Multi Paxos

Fast Paxos

参考资料

• The Part-Time Parliament —— Leslie Lamport
• 分布式算法 Paxos 的直观解释

1962 年美国订制了一套统一三军的航空器命名规范, 在此全面梳理一下, 方便学习与记忆;

普通飞行器命名规则

以状态为前缀命名

• G: 永久停飞
• J: 暂时特别测试 (Special test, temporary)
• N: 永久特别测试 (Special test, permanent)
• X: 实验机
• Y: 原型机
• Z: 纸上计划

以任务为后缀命名

表示航空器的主要任务类型:

• A: 攻击机 (Attack aircraft)
• B: 轰炸机 (Bomber)
• C: 运输机 (Transport)
• E: 电子战机 (Special electronic installation)
• F: 战斗机 (Fighter)
• K: 加油机 (Tanker)
• H: 直升机 (Helicopter)
• L: 激光测试机 (Laser-equipped)
• O: 前线观测机 (Observation)
• P: 海上巡逻机 (Maritime patrol)
• R: 侦察机 (Reconnaissance)
• S: 反潜机 (Anti-submarine warfare)
• T: 教练机 (Trainer)
• U: 通用机 (Utility)
• X: 实验机 (Special research)

举例

• F-22: “猛禽” 战斗机
• B-2: “幽灵” 轰炸机
• B-21: “地狱犬” 轰炸机
• E-2: “鹰眼” 预警机
• A-10: “疣猪” 对地攻击机
• C-5: “银河” 运输机
• C-17: “环球霸王” 运输机
• C-130: “大力神” 运输机
• V-22: “鱼鹰” 人员运输直升机

以任务为前缀命名

表示航空器所执行的任务是附加在原主要任务之上的不同任务:

• A: 对地攻击 (Attack)
• C: 运输 (Transport)
• D: 靶机拖曳 (Drone director)
• E: 特殊电子战 (Special electronic mission)
• F: 空中优势战斗 (Fighter)
• H: 搜索与救援 (Search and rescue, MEDEVAC)
• K: 空中加油 (Tanker)
• L: 极端天气任务 (Equipped for cold weather operations)
• M: 导弹运载 (Missile carrier 1962 – 1972 年), 反水雷 (Mine countermeasures 1973 – 1976 年), 多任务 (Multi-mission 1977 年起一直延用)
• O: 侦测 (Observation)
• P: 海上巡逻 (Maritime patrol)
• Q: 无人操作 (Unmanned drone)
• R: 侦察 (Reconnaissance)
• S: 反潜 (Antisubmarine warfare)
• T: 教练 (Trainer)
• U: 通用 (Utility)
• V: 人员输送 (Staff transport)
• W: 天气观测 (Weather reconnaissance)

举例

• EA-18G: “咆哮者” 电子战机
• EP-3C: “” 电子侦察机
• UH-60: “黑鹰” 通用直升机
• AH-64: “阿帕奇” 武装直升机
• CH-47: “支奴干” 运输直升机
• HH-60: “铺路鹰” 搜救直升机
• SR-71: “黑鸟” 侦察机
• YF-22: 第五代空优战斗机验证机 (F-22 原型机)
• QF-16: “战隼” F-16 的无人操作改型
• KC-135: 加油机
• WC-130: “飓风猎人” 气象观测机
• LC-130: 极地保障运输机

导弹/火箭命名规则

美国导弹和火箭一般以三位字母 + 编号命名, 其中三位字母分别代表:

• 武器的发射载台/环境
• 武器的主要任务
• 武器的类型

首字母代表:

次字母代表:

末字母代表:

举例

• 战斧巡航导弹
  • BGM-109: 陆基型
  • AGM-109: 空射型
  • UGM-109: 潜射反舰型
  • RGM-109: 舰射型
• 鱼叉反舰导弹
  • AGM-84: 空射型
  • RGM-84: 舰射型
  • UGM-84: 潜射型
• 先进中程空空导弹:
  • AIM-120: 空射型

参考链接

• 1962年美国三军航空器命名体系

kafka 在协调机制下实现无感切流 & 受控关机是一个复杂的流程, 且在 zookeeper 时代和 KRaft 时代下的处理逻辑迥异;
通过 ZK 和 KRaft 两种机制对该场景处理的差异, 我们也能体会到 KRaft 模式对于 kafka 革命般的意义;

Zookeeper 下的 broker 受控关机流程

假设一个 kafka 集群初始状态如下:

初始状态

目标 Broker 向 Controller 请求关机

ControlledShutdownRequest

当在 Broker-0 机器上执行 kill kafka broker 进程的命令, 该机器上的 broker 进程响应命令, 会先向 Controller 发送 ControlledShutdownRequest, 随后进程阻塞, 等待 Controller 的回复;

Controller 处理 Broker 关机请求

当 Controller 接收到 ControlledShutdownRequest 后, 将会对目标 broker 上的每一个 topic 的每一个 partition 依次执行以下步骤:

1. Controller 会检查下线的 broker 是否是目标 partition 的 leader, 如是, 则 Controller 需要为该 partition 重新选举新的 leader:
   • Controller 会从该 partition 的 ISR (In-Sync Replicas) 列表中选择一个新的 leader, 默认选择 ISR 列表中的第一个副本作为新的 leader;
   • 如果 ISR 列表为空, Controller 会根据配置决定是否允许从非同步副本 (Out-of-Sync Replicas) 中选举 leader (通过配置 unclean.leader.election.enable);
2. 收缩 ISR, 将下线的 broker 上的 partition 副本从 ISR 中摘除:
   从:

   

   变为:

   

3. 将最新的 ISR 和 leader 信息写入 zookeeper;
4. Controller 以同步阻塞的方式依次向目标 partition 其他副本所在的 broker 发送 LeaderAndIsrRequest:
   • 收到请求的 broker 从请求中解析出 leader、ISR 等信息并存储到本地后, 响应 Controller;
   • Controller 收到上一个 broker 的成功响应后才会向下一个 broker 发送请求;

Broker 正式下线

当 Controller 处理完所有的 topic 的 partition 后, 会向最初发起请求关机的 Broker-0 回复 ControlledShutdownResponse, 此时 Broker-0 正式结束进程;

性能改善

• 在 kafka 1.1.0 之前, 以上过程是单线程全程同步阻塞执行的, 耗时很长;
  • 分区在重新选举 leader 时, 会暂停对外提供读写服务, 严重时会导致生产故障;
• 从 kafka 1.1.0 开始, kafka 将上述过程改为多线程异步非阻塞的方式执行, 显著提升了处理速度;

KRaft 下的 broker 受控关机流程

参考资料

• Kafka中的KRaft算法

redis 的线程模型从最刚开始的纯单线程, 到引入异步线程处理耗时操作, 再到最终使用多线程处理 IO 读写操作, 完成了线程模型的全面升级重构;
和普通常见的 IO 密集型应用不同, redis 作为一个内存密集型应用, 使用了绝无仅有的 多线程处理 IO、单线程处理核心逻辑 的模式, 值得我们学习了解, 也为我们在日常工作中, 跳出传统思维框架, 紧贴自身业务特征做最合适的技术选型提供了启发与参考;

单线程模型

redis 单线程模型

借助于 linux epoll I/O 多路复用机制, redis 可以仅凭单线程实现高效的客户端请求处理一条龙服务:

• 读取数据
• 命令解析
• (合并请求)
• 命令执行
• 结果写回客户端缓冲区

因为单线程无需考虑锁竞争、线程安全及事务可见性等多线程才会引入的问题, 且不存在线程切换的开销, redis 单线程可以支撑起非常高的单机 qps;

异步线程

redis 存在文件事件与时间事件两种事件类型, 对于事件的处理 redis 只在单独的主线程中做, 但是在很多其他逻辑的处理上, 并不是使用单线程:

• 生成 RDB 文件: fork 一个子进程来实现;
• big key 删除: 引入了 Lazy Free 机制将其异步化, 主线程只做关系解除以快速返回, 方便继续处理其他事件;

多线程模型

redis 几乎不存在 CPU 或者线程成为瓶颈的情况, 而是主要受限于内存和网络带宽, 即 redis 执行期间大部分 CPU 时间片是用来等待 IO 读写和网络传输;
所以 redis 6.0 为了解决 IO 读写的瓶颈, 引入了多线程以提升 IO 读写性能, 但同时也保留了事件处理的单线程特性, 从而保留了 redis 传统的高效率;

redis 多线程模型

redis 的 IO 线程代替原本的主线程做了如下事情:

• 读取数据
• 命令解析
• (合并请求)
  ……
• 结果写回

只有最核心的命令执行是交给了主线程去做; 可以看到, 只要不涉及数据状态的操作, 都可以交给 IO 多线程而不用关心线程安全等问题;

多线程特性的启用

redis 6.0 默认是不开启多线程特性的, 如果需要使用多线程功能, 需要在 redis.conf 中完成两个设置:

1
2
3
4

# 启用多线程
io-thread-do-reads yes
# 线程数量
io-threads 6

线程个数要小于 Redis 实例所在机器的 CPU 核个数, 例如对于一个 8 核的机器来说, redis 官方建议配置 6 个 IO 线程;

更高效的实现: Tair RDB 多线程模型

阿里巴巴的缓存产品 Tair RDB 实现了更高效的多线程请求模型:

tair rdb 的线程模型

• Main Thread: 负责客户端连接建立等;
• IO Thread: 负责请求读取、响应发送、命令解析等;
• Worker Thread: 专门用于事件处理、命令执行;

IO Thread 读取用户的请求并进行解析, 之后将解析结果以命令的形式放在队列中发送给 Worker Thread 处理;
Worker Thread 将命令处理完成后生成响应, 通过另一条队列发送给 IO Thread;
为了提高线程的并行度, IO Thread 和 Worker Thread 之间采用无锁队列和管道进行数据交换;

参考资料

• Redis6.0多线程的实现原理是什么？
• Redis的多线程到底该怎么理解

MySQL 从 5.7.8 版本开始支持原生 JSON 数据类型; 这是一种非常实用的类型, 允许我们免于设计复杂的表关系结构, 从而更加专注于业务本身;

查询指定的 json 字段

json 内容举例:

1
2
3
4

{
    "type": "XXX",
    "content": "YYY"
}

查询条件为 json 对象中指定字段是否为指定的值:

1

SELECT * FROM `table_name` WHERE `field_name`->'$.type' = 'XXX'

查询 json 数组是否存在指定 value

json 内容举例:

1

[1, 2, 3, 4, 5]

查询条件为 json 数组中是否存在指定的值:

1
2

SELECT * FROM `table_name` WHERE json_contains(`field_name`, '4')
SELECT * FROM `table_name` WHERE json_contains(`field_name`, json_array(1, 4))

查询 json 对象是否存在指定 key

json 内容举例:

1
2
3
4
5
6
7
8
9

{
  "type" : "XXX",
  "content" : {
    "subField1" : 1,
    "subField2" : 2,
    "subField3" : 3,
    "subField4" : 4
  }
}

查询条件为 json 对象中是否存在指定的字段 (json_contains_path 函数第二个入参表示 anyMatch 或者 allMatch):

1
2
3
4
5

SELECT * FROM `table_name` WHERE json_contains_path(`field_name` -> '$.content', 'one', '$."subField2"')
// subField1 和 subField5 只要存在一个就匹配
SELECT * FROM `table_name` WHERE json_contains_path(`field_name` -> '$.content', 'one', '$."subField1"', '$."subField5"')
// subField1 和 subField5 必须都存在才匹配
SELECT * FROM `table_name` WHERE json_contains_path(`field_name` -> '$.content', 'all', '$."subField1"', '$."subField5"')

拼接 json

语法: JSON_INSERT(json, path1, value1[, path2, value2] …)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

select version, gmtModified, recordStatus, spec, recordType from (
    select  revision as version, 
            gmt_modified as gmtModified,
            CASE WHEN record_status = 'LATEST' THEN 'LATEST' ELSE 'OUTDATED' END as recordStatus,
            JSON_INSERT('{}', '$.meta', api_meta, '$.traffic', traffic_distributions, '$.policies', policies) as spec,
            'draft' as type 
    from `ultramax_api_draft_history` where name = 'RPC^com.mtop.custom.type^1.0'
    union all
    select  version as version,
            gmt_modified as gmtModified,
            CASE WHEN record_status = 'VALID' THEN 'LATEST' ELSE 'OUTDATED' END as recordStatus,
            JSON_INSERT('{}', '$.meta', api_spec, '$.traffic', traffic_distributions, '$.policies', plan) as spec,
            'daily_snapshot' as type
    from `ultramax_api_snapshot_history_daily` WHERE `name` = 'RPC^com.mtop.custom.type^1.0'
  ) as merge
ORDER BY t desc, v desc
limit 10

参考资料

• MySQL的json查询之json_contains、json_contains_path

之前对列式存储接触的不太多, 我想从 hbase 入手, 学习一下列式数据库的基本原理和存储结构;

逻辑结构

hbase 不是传统的列式存储结构, 而是按列族聚合的存储结构;

hbase 表的行结构:

1
2

# 按照 rowkey 的字典序升序排列
(rowkey, columnFamily, column) -> (value, timestamp)

1

SortedMap<RowKey, List<SortedMap<Column, List<value, Timestamp>>>>

详细示例

逻辑数据

表结构

列族定义:

• basic_info (基本信息)
  • 列: name, age
• contact_info (联系信息)
  • 列: email, phone
• activity_info (活动信息)
  • 列: last_login, login_count

建表语句:

1

create 'my_table', {NAME => 'basic_info', VERSIONS => 1}, {NAME => 'contact_info', VERSIONS => 1}, {NAME => 'activity_info', VERSIONS => 1}

物理存储的逻辑结构

hbase 在磁盘上会按列族分开存储, 每个列族对应一个独立的存储文件 (HFile), 以下是实际存储的逻辑视图:

• 列族 basic_info 的存储文件

  1 2 3 4 5 6

  RowKey | Column Qualifier | Timestamp | Value ----------|------------------|---------------|--------- user001 | name | 1692066600000 | 张三 user001 | age | 1692066600000 | 28 user002 | name | 1692159300000 | 李四 user002 | age | 1692159300000 | 32

• 列族 contact_info 的存储文件

  1 2 3 4 5 6

  RowKey | Column Qualifier | Timestamp | Value ----------|------------------|---------------|----------------------- user001 | email | 1692066600000 | zs@ele.com user001 | phone | 1692066600000 | 13800138001 user002 | email | 1692159300000 | ls@ele.com user002 | phone | 1692159300000 | 13900139002

• 列族 activity_info 的存储文件

  1 2 3 4 5 6

  RowKey | Column Qualifier | Timestamp | Value ----------|------------------|---------------|----------------------- user001 | last_login | 1692066600000 | 10:30:00 user001 | login_count | 1692066600000 | 42 user002 | last_login | 1692159300000 | 14:15:00 user002 | login_count | 1692159300000 | 27

参考资料

• HBase 存储原理

mysql 提供的 explain 执行计划能力是我们做 sql 调优的好帮手, 甚至可以说是我们观察 sql 执行效率的重要理论依据;
学好并用好 mysql explain 可以方便地写出高效率的 sql;

explain 详细说明

type