MySQL 数据模型

教学版用四张表表达 Durable Execution 和业务落地的关系。其中前三张属于运行时，最后一张属于订单业务域。

invocations

Invocation 是一次 durable handler 执行。

CREATE TABLE invocations (
  id VARCHAR(36) PRIMARY KEY,
  workflow_type VARCHAR(100) NOT NULL,
  idempotency_key VARCHAR(255) UNIQUE,
  status VARCHAR(32) NOT NULL,
  input JSON NOT NULL,
  result JSON NULL,
  error TEXT NULL,
  attempt_count INT NOT NULL DEFAULT 0,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL
);

状态说明：

状态	含义
QUEUED	已创建，等待 worker 执行
RUNNING	worker 正在执行
RETRYABLE	发生可重试错误
WAITING_TIMER	等待 durable timer 到期
COMPLETED	已完成
FAILED	预留给不可重试错误

journal_entries

Journal 记录每个 durable step 的事实。

CREATE TABLE journal_entries (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  invocation_id VARCHAR(36) NOT NULL,
  step_index INT NOT NULL,
  step_name VARCHAR(255) NOT NULL,
  status VARCHAR(32) NOT NULL,
  result JSON NULL,
  error TEXT NULL,
  created_at DATETIME NOT NULL,
  UNIQUE KEY uq_invocation_step (invocation_id, step_index)
);

唯一键 (invocation_id, step_index) 保证每个步骤只提交一次。

runtime_events

这张表不是 Durable Execution 必需品，但对教学很有帮助。它记录 worker 的调度、重试、暂停、恢复等事件，前端可以展示运行时发生了什么。

CREATE TABLE runtime_events (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  invocation_id VARCHAR(36) NOT NULL,
  message VARCHAR(500) NOT NULL,
  created_at DATETIME NOT NULL
);

business_orders

这张表是业务系统真正关心的订单表。Durable Execution 不替代业务表，它负责让业务表的多步骤更新在故障后继续推进。

CREATE TABLE business_orders (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_id VARCHAR(64) UNIQUE NOT NULL,
  invocation_id VARCHAR(36) UNIQUE NOT NULL,
  sku VARCHAR(100) NOT NULL,
  quantity INT NOT NULL,
  amount DOUBLE NOT NULL,
  status VARCHAR(32) NOT NULL,
  payment_id VARCHAR(64) NULL,
  reservation_id VARCHAR(64) NULL,
  receipt_id VARCHAR(64) NULL,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  KEY ix_business_orders_invocation (invocation_id),
  KEY ix_business_orders_status (status)
);

订单状态流转：

为什么不直接用一张任务表

一张任务表只能表达“任务整体现在是什么状态”。Durable Execution 需要表达“任务内部哪些步骤已经成为事实”。

数据粒度	能回答的问题
invocations.status	这个 workflow 是否完成、是否需要重试
journal_entries	第几个 durable step 是否已经提交、结果是什么
runtime_events	worker 最近做过哪些调度动作
business_orders	订单对业务系统暴露的状态是什么

没有 Journal，你只能从头重试；有 Journal，才能跳过已经完成的副作用。

没有业务表，workflow 只能证明“运行时做过什么”，却不能回答“订单现在是什么状态”。真实业务系统通常两者都需要。