E6 - 状态物化：从事件流到本地状态

状态物化 = 从事件流构建服务的本地视图——查询响应快 + 事件流仍是 SSOT = 性能与一致的平衡。

一句话

物化 = 应用 Entity Events 顺序到本地存储；最新 Entity Event = 当前状态；物化策略 = 完整 / 增量 / 混合。

这本书在这一层说了什么

本层基于 EDM Ch 7 完整精读（42KB / 6552 词）。

Bellemare Ch 7 关键洞察：

"Entity events are particularly important in event-driven architectures... A materialization operation rebuilds the state of the service from the events themselves."

核心论点 5 个：

1. Materializing Global State — 全局 vs 局部物化
2. Advantages of Using Internal State — 内部状态的 4 大好处
3. High-Performance Disk-Based Options — 本地磁盘 vs 网络磁盘
4. Scalability and Distribution — 扩缩容
5. Event Sourcing — 事件溯源作为物化的特例

是什么

1. 为什么需要物化

Bellemare 关键洞察：

"A materialization operation rebuilds the state of the service from the events themselves."

根本：事件流是"过去"，查询需要"现在"。没有物化，查询就要重放所有事件 → 性能灾难。

物化的双重身份：

• 历史 = 事件流（SSOT）
• 当前 = 物化的本地状态（查询快）

2. 物化 3 种策略

Bellemare Ch 7 详细分析：

策略 1: 完整物化（Full Materialization）

启动时：
  - 消费所有历史事件
  - 重建本地状态
  - 启动后才接受新事件

优点：

• 实现简单
• 状态完整性保证

缺点：

• 启动慢（事件多时）
• 不能"中途加入"

策略 2: 增量物化（Incremental Materialization）

启动时：
  - 从最近 offset 开始
  - 不消费历史事件
  - 逐步构建状态
  
运行中：
  - 持续消费新事件
  - 增量更新本地状态

优点：

• 启动快（无历史重放）
• 可中途加入

缺点：

• 启动时状态不完整
• 业务需要容忍"短暂不完整"

策略 3: 混合（Hybrid）

启动时：
  - 加载最新快照（snapshot）
  - 从快照 offset 之后增量消费
  
运行中：
  - 持续消费
  - 定期生成新快照

优点：

• 启动快 + 状态完整
• 适合超大事件量

缺点：

• 实现复杂（快照管理）

3. 物化类型 3 种（存储介质）

Bellemare Ch 7 关键论断：

类型	性能	成本	适用
内存	极快（百万读/秒）	高	小状态 + 高频访问
本地 SSD	快（15.4K 读/秒 RocksDB）	中	大状态 + 中频访问
网络磁盘	慢（939 读/秒 @ 1ms RTT）	低	大状态 + 低频访问

Bellemare 关键数据：

"The latency for a random-access read from an SSD using RocksDB is approximately 65 microseconds... 15.4k requests/second."

"Introducing a network latency of only 1 mS round-trip time to an identical access pattern reduces the throughput cap to just 939 requests/second."

关键洞察：网络磁盘慢 16 倍——物理本地 SSD 不可替代。

4. 内部状态 vs 外部数据库

Bellemare 关键论断：

"A major benefit of using internal state stores on local disk is that all scalability requirements are fully offloaded to the event broker and compute resource clusters."

内部状态的好处：

1. 可扩展性卸载给基础设施团队
   - 开发者只关注业务逻辑
   - 扩缩容由 K8s / Cluster 管理
   
2. 单实例扩缩容 = 增加副本
   - 不需要复杂的分布式协调
   
3. 性能高
   - 本地 SSD = 微秒级
   - 内存 = 纳秒级
   
4. 灵活性
   - 物理本地 SSD = 高性能
   - 网络磁盘 = 易迁移

5. 全局状态物化（Global vs Local）

Bellemare 关键定义：

"A global state store is a special form of the internal state store. Instead of materializing only the partitions assigned to it, a global state store materializes the data of all partitions for a given event stream, providing a complete copy of the event data to each microservice instance."

全局 vs 局部：

类型	数据范围	适用
局部	本实例负责的 partition	业务驱动的物化
全局	全部 partition	通用查找 + 维度表

Bellemare 关键警告：

"Global materialization cannot be effectively used as the driver for event-driven logic, as each microservice instance possesses a full copy of the data and thus would produce duplicate outputs and nondeterministic results."

关键洞察：全局物化不能驱动业务逻辑（会导致重复处理）——只能用于查找/维度表。

6. 事件溯源作为物化的特例

Bellemare 关键论断：

"Event sourcing is a specific application of the materialized state pattern, where the service's state is built from the event stream and the events are the source of truth."

事件溯源 = 物化的特例：

• 物化 = "事件 → 状态"
• 事件溯源 = "事件 → 状态"（事件是 SSOT）

区别：

• 普通物化：状态在 DB，事件流辅助
• 事件溯源：事件流是真理，状态是"投影"

为什么

为什么需要本地物化（不查询数据库）？

反例（无物化）：

• 每请求都重放所有事件 → O(n) → 不可接受

物化：

• 启动时构建（一次性成本）
• 查询时直读本地 → O(1) → 高性能

为什么事件流仍是 SSOT？

根因：物化状态是"派生数据"——可以从事件流重建。

好处：

• 业务变化 → 重放事件 → 重建新状态
• 灾难恢复 → 从事件流恢复
• 新服务加入 → 从事件流物化

为什么本地 SSD 比网络磁盘快 16 倍？

Bellemare 关键数据：

• SSD RocksDB: 65 微秒 → 15.4K 读/秒
• 网络磁盘 + 1ms RTT: 939 读/秒

根因：物理距离 = 光速限制。网络往返 1ms 是不可避免的物理延迟。

为什么全局物化不能驱动业务逻辑？

反例：

• 3 个微服务实例都全局物化订单流
• 每个实例都看到所有 OrderCreated 事件
• 每个实例都处理 → 重复扣库存 3 次

Bellemare 关键洞察：

"Global materialization cannot be effectively used as the driver for event-driven logic."

修复：用 partition 分配（每实例只负责部分 partition → 唯一处理）。

怎么做

Step 1：选择物化策略

决策树：
  Q1: 事件量 < 10万/天 + 启动时间 < 1分钟？
    是 → 完整物化
    否 ↓
  Q2: 事件量 > 10万/天 或 启动时间敏感？
    是 → 增量物化
    否 ↓
  Q3: 事件量 > 100万/天 或 需要毫秒级启动？
    是 → 混合（快照 + 增量）

Step 2：本地物化实现（增量 + RocksDB）

from kafka import KafkaConsumer
import rocksdb

# 持久化 offset
db = rocksdb.DB('/data/local-store/', rocksdb.Options(create_if_missing=True))
consumer = KafkaConsumer(
    'orders',
    bootstrap_servers='kafka:9092',
    group_id='order-materializer',
    enable_auto_commit=False
)

last_offset = db.get(b'last_offset') or 0

for message in consumer:
    if message.offset <= last_offset:
        continue
    event = json.loads(message.value)
    # 物化逻辑
    db.put(f"order:{event['orderId']}".encode(), json.dumps(event).encode())
    db.put(b'last_offset', str(message.offset).encode())

Step 3：选择存储介质

决策树：
  Q1: 状态 < 1GB？
    是 → 内存
    否 ↓
  Q2: 性能要求 > 1000 读/秒？
    是 → 本地 SSD（RocksDB）
    否 → 网络磁盘（便于迁移）

Step 4：定期校验物化一致性

# 离线校验：随机抽样事件 → 重放 → 比对当前物化状态
def verify_consistency(sample_events):
    for event in sample_events:
        expected_state = replay(event)
        actual_state = db.get(f"order:{event['orderId']}")
        assert expected_state == actual_state, f"Drift: {event}"

Step 5：实现事件溯源（可选）

# CQRS 模式
class EventStore:
    def append(self, event):
        """追加事件（永不修改）"""
        self.db.append(event)
    
    def get_events(self, aggregate_id):
        """获取所有事件"""
        return self.db.query(f"aggregate_id={aggregate_id}")

# Projection（投影）
class OrderProjection:
    def apply(self, event):
        """应用事件到当前状态"""
        if event.type == "OrderCreated":
            self.orders[event.order_id] = {
                'id': event.order_id,
                'customer_id': event.customer_id,
                'status': 'CREATED'
            }
        elif event.type == "OrderPaid":
            self.orders[event.order_id]['status'] = 'PAID'
    
    def rebuild(self, aggregate_id):
        """从事件流重放"""
        events = event_store.get_events(aggregate_id)
        for event in events:
            self.apply(event)
        return self.orders.get(aggregate_id)

什么时候用 / 什么时候不用

用本地物化的 2 大场景

场景	关键判断
读多写少 + 性能敏感	查询毫秒级响应 → 本地物化
服务需要自治	不共享数据库 → 本地物化

用共享存储的 1 大场景

场景	关键判断
跨服务实时查询	必须 JOIN 多服务数据 → 共享

用事件溯源的 1 大场景

场景	关键判断
业务需要完整审计 + 时间旅行	金融、医疗、合规 → 事件溯源

看不见的地方

失效模式 1：物化数据漂移

症状：物化状态 ≠ 真实事件流状态 → 业务查询错误。

根因：消费过程中途失败 + offset 未提交 → 重启后跳过事件。

修复：offset 提交必须在物化成功后（at-least-once + 幂等处理）。

失效模式 2：启动时间爆炸

症状：完整物化 1 亿事件 → 启动 30 分钟 → 服务不可用。

根因：未考虑启动性能。

修复：用增量物化 + 定期快照 + 启动时"快照 + 增量"。

失效模式 3：本地存储容量爆炸

症状：本地 RocksDB 占满磁盘 → 服务崩溃。

根因：物化策略不当（保留过多历史数据）。

修复：物化只保留"当前状态" + 冷数据归档 + 监控磁盘使用。

失效模式 4：全局物化导致重复处理

症状：3 个实例都处理同一 OrderCreated → 重复扣库存。

根因：全局物化被误用为业务逻辑驱动。

修复：业务逻辑用 partition 局部物化；全局物化只用于查找/维度。

失效模式 5：事件溯源查询性能差

症状：订单查询秒级响应 → 业务无法接受。

根因：直接查 Event Store 需要重放所有事件。

修复：CQRS + 专门的 Projection 读模型 + 物化视图。

相关节点

骨架 A — 世界观

节点	关联	解释
wonder-03-emergence-time	强	状态物化 = "时"凝固——事件流时间凝固成当前状态
wonder-01-emergence-vision	中	物化视图 = "涌现视域"——每服务有自己的视域

骨架 B — 工程实践

节点	关联	解释
value-stream	强	状态物化 = 价值流的"沉淀"——价值从流变成可用状态
metrics-improvement	中	物化一致性校验 = 度量——定期度量保证系统健康

状态

E6 概念递进落地完成（基于原书 ch07 42KB / 6552 词）。

• 5 个核心论点（为什么物化 / 3 策略 / 3 存储介质 / 全局 vs 局部 / 事件溯源）
• 5 步怎么做（含完整 RocksDB 物化代码 + 事件溯源实现）
• 5 个失效模式
• 骨架 A/B 完整映射