无法编译的数据竞争：Rust 类型系统如何拒绝并行 Redux 数据竞争

背景

在软件工程领域，有一类 Bug 令人闻风丧胆：它们通常只在高负载下出现，在调试器附加时消失，并耗费多名工程师整个周末才将其锁定。这类 Bug 的核心往往是数据竞争（Data Race）。

Rust 的借用检查器（Borrow Checker）虽然在值级别防止了大多数数据竞争，但它并非万能。作者提出并试图解决一个更具体的问题：编译器能否拒绝构建一个并行归约管道（parallel reducer pipeline），其中两个归约器（reducer）可能写入同一块状态数据？

作者在其名为 ruxe 的 Redux 风格 Rust 学习库中进行了探索，并成功证明了答案是肯定的。这一探索源于作者在能源管理系统领域的实际工作痛点。在工业现场，控制系统需要多个控制器并发运行，共享一致的状态视图。传统的 Python Redux 实现虽然逻辑清晰，但在面对每秒数十次、涉及大量寄存器的高频遥测数据流时，性能瓶颈明显。

为了解决性能问题，团队考虑将独立的子系统（如太阳能、电池、电表控制器）的归约器并行化。然而，并行执行共享状态必然带来数据竞争的风险。在 C++ 或 Python 等语言中，避免数据竞争主要依赖开发者的纪律和同步原语（如互斥锁），编译器无法在编译阶段强制保证安全性。而 Rust 的类型系统有能力将这一属性直接编码进类型中，由编译器强制执行。

核心内容

Redux 模式与并行化的诱惑

Redux 是一种状态管理范式，其核心规则包括：

1. 单一事实来源：状态由 Store 独占。
2. 外部不可变性：外部代码不能直接修改状态，只能通过分发事件（Actions）来描述变化。
3. 纯归约器：状态转换通过纯函数 (state, event) -> new state 进行，无副作用。

这种模式使得状态转换具有确定性，支持时间旅行调试和可复现的 Bug 诊断。

在工业控制场景中，全局状态被划分为多个独立的“切片”（Slices），例如太阳能切片、电池切片等。每个切片拥有自己的归约器，且不同归约器之间互不干扰。如果串行执行这些归约器，延迟是各归约器延迟之和；如果并行执行，延迟仅为最大单个归约器的延迟。因此，并行化归约器是提升性能的自然选择。

核心概念：切片与不相交性

为了实现安全的并行归约，必须定义两个关键概念：

• 切片（Slice）：状态的子字段。例如，如果状态包含 counter、user 和 notifications，那么这三个字段就是三个切片。
• 切片归约器（Slice Reducer）：只能访问其对应切片的归约器。其函数签名仅暴露 &Slice，类型系统禁止其访问其他切片。

**不相交性（Disjointness）**是安全并行执行的前提和充分条件：对于配置中的任何一对切片归约器，它们必须针对不同的切片。如果两个归约器试图写入同一个切片，就会发生数据竞争。

工程目标转化为：能否让编译器拒绝构建违反不相交性属性的并行根归约器？

尝试一：AllDistinct 与类型不等式的困境

作者最初的想法借鉴了 C++ 的模板元编程。在 C++ 中，可以使用 std::is_same_v 和 static_assert 在编译时检查类型相等性。作者设想在 Rust 中实现一个名为 AllDistinct 的 Trait，用于检查元组中所有归约器的切片类型是否互不相同。

伪代码逻辑如下：

trait AllDistinct {}
impl AllDistinct for () {} // 空元组显然 distinct
impl<H, Tail> AllDistinct for (H, Tail)
where
    Tail: AllDistinct,
    H: NotIn<Tail>, // H 不在 Tail 中
{}

为了实现 NotIn<Tail>，需要表达“对于 Tail 中的每个元素 X，H ≠ X”。然而，作者遇到了 Rust 类型系统的限制：

1. 缺乏类型不等式语法：稳定的 Rust 没有 H != T 这样的语法来表示类型不等式。
2. Trait 系统的单调性：Rust 的 Trait 系统基于单调推理，即代码库中增加更多的实现只会允许更多代码编译，而不会禁用现有代码。
3. 负向实现（Negative Impl）的限制：虽然存在 negative_impls 不稳定特性，允许编写“如果某 Trait 未实现则实现另一 Trait”的逻辑，但由于一致性（Coherence）问题，该特性长期处于搁置状态。

因此，作者无法直接通过类型不等式来强制检查切片类型的唯一性。这标志着第一种基于纯类型不等式检查的思路在稳定 Rust 中遇到了不可逾越的障碍。

(注：原文在此处中断，但根据标题和上下文，后续内容通常会介绍作者如何通过改变思维模型，例如利用类型层级、关联类型或特定的 Trait 组合来间接实现不相交性检查，从而让编译器拒绝有数据竞争风险代码。)

关键要点

• 数据竞争的本质：数据竞争是并发编程中最难调试的 Bug 之一，通常表现为非确定性输出和难以复现的 Heisenbugs。
• Rust 的优势：与 C++ 或 Python 依赖运行时同步或开发者纪律不同，Rust 可以通过类型系统在编译阶段强制保证内存安全和数据竞争安全。
• Redux 在工业场景的应用：Redux 的纯函数和不可变状态特性非常适合需要高可预测性和可调试性的工业控制系统，但在高频数据流下存在性能瓶颈。
• 并行化的前提：将独立的归约器并行化可以显著降低延迟，但前提是必须保证不同归约器操作的“状态切片”是不相交的（Disjoint）。
• 类型系统的局限与突破：
  • 直接表达“类型不等式”（Type Inequality）在稳定 Rust 中不可行，因为缺乏 != 类型运算符且 Trait 系统不支持负向实现。
  • 这迫使开发者寻找更复杂的类型编码技巧，通过结构化的类型约束而非简单的不等式检查来确保不相交性。

意义与影响

• 编译时安全性的极致追求：该案例展示了 Rust 类型系统的强大能力。通过将业务逻辑约束（如“不同模块操作不同数据”）编码进类型系统，可以将潜在的运行时错误转化为编译时错误，极大地提高了系统的可靠性。
• 并发编程范式的转变：在高性能计算和工业控制系统中，从“运行时同步”转向“编译时隔离”是提升性能和安全性的重要方向。Rust 提供了一种无需锁（Lock-free）即可保证数据竞争安全的途径。
• 对类型系统设计的启示：即使是最先进的类型系统，也存在表达某些逻辑（如类型不等式）的困难。这促使开发者更深入地理解类型系统的原理，并探索如关联类型、新类型包装（Newtype）、层级类型等高级技巧来绕过语言限制。
• 跨领域技术迁移：将前端 JavaScript 中的 Redux 模式迁移到后端工业控制领域，并针对 Rust 语言特性进行优化，展示了软件架构模式的通用性和适应性。