# 信号 Push-Pull 算法：响应式系统的双向数据流设计 > 解析响应式编程中 Push-Pull 混合算法的工程实现：脏标记机制、依赖追踪与无冲突更新。 ## 元数据 - 路径: /posts/2026/04/06/signals-push-pull-algorithm/ - 发布时间: 2026-04-06T14:25:08+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 在现代前端框架和响应式系统设计中，信号（Signals）已经成为一种重要的状态管理范式。而 Push-Pull 算法作为实现信号系统的核心机制，结合了推模式与拉模式的优点，能够在保证数据一致性的同时实现高效的细粒度更新。本文将从工程实现的角度，深入剖析 Push-Pull 算法的设计原理与关键参数。 ## 响应式系统的基本需求 在设计响应式引擎时，我们需要满足几个核心需求。首先是高效性：每个计算单元在单次更新周期内最多只计算一次，不会执行任何立即被丢弃的计算。其次是细粒度：只有受到输入变化影响的节点才会被更新，未受影响的节点保持不变。第三是无冲突性：当节点值发生变化时，所有相关节点同时更新，不存在中间状态可供外部观察。第四是动态性：每次计算时节点可以动态添加或移除依赖关系。 传统的 Push（推）模式和 Pull（拉）模式各有优劣。Push 模式在输入变化时立即向下游推送更新通知，优点是延迟低、通知精准，但缺点是容易产生重复计算，且难以保证无冲突性。Pull 模式则在需要时从上向下拉取数据，天然具备无冲突性，但可能导致大量不必要的计算。Push-Pull 混合模式正是为了解决这些问题而提出的。 ## Push 阶段：脏标记传播 Push 阶段的核心任务是识别哪些节点需要更新，而不是真正执行更新。具体实现上，每个节点维护一个布尔类型的脏标记（dirty flag）。当输入节点发生变化时，系统从该节点出发，递归遍历其所有下游节点。遍历算法遵循以下规则：如果当前节点已被标记为脏，则跳过；如果未被标记，则将其标记为脏，并根据节点类型决定后续行为——对于输出节点，将其加入待更新列表；对于中间节点，则继续递归访问其子节点。 这种设计的关键优势在于遍历顺序无关性。传统 Push 模式需要计算拓扑排序来确定最优更新路径，而 Push-Pull 模式只需简单递归并跳过已脏节点即可。这意味着节点只需维护直接上游和下游的邻接关系，无需维护全局有序列表，大大降低了动态依赖场景下的实现复杂度。 ## Pull 阶段：按需计算与缓存 识别出需要更新的节点后，Pull 阶段负责实际执行计算。与简单 Pull 模式不同的是，此时系统已经明确知道哪些输出节点需要更新，因此可以精确地只计算这些节点。计算过程中，每个节点检查自身状态：如果节点是干净的，直接返回缓存的计算结果；如果节点是脏的，则递归计算所有上游依赖项，标记自身为干净，并存储计算结果。 Pull 阶段的缓存机制是性能关键。常用的实现方式包括生成计数器（generation counter）和 LRU 缓存。生成计数器方案较为简单：每次输入变化时递增全局计数器，所有缓存值随之失效。LRU 缓存则更精细，可以保留部分近期使用过的计算结果，但需要额外处理缓存失效逻辑。 ## 无冲突更新的保证 Push-Pull 模式能够天然保证无冲突性，原因在于整个 Pull 过程在一个完整的执行周期内完成。只要在 Pull 阶段执行期间不修改任何输入节点，所有节点看到的就是一致的输入状态。在单线程运行时（如 JavaScript）中这个条件很容易满足；在多线程场景下，则需要使用简单的锁机制确保 Pull 阶段完全结束后才允许修改输入。 这种设计避免了传统 Push 模式中节点间状态不一致的问题。在 Push 模式下，节点 A 更新后可能立即触发节点 B 的更新，但节点 C 尚未更新，此时外部观察者可能看到不一致的中间状态。Push-Pull 模式将更新分为识别和执行两个阶段，有效规避了这一风险。 ## 工程实践参数建议 在实际实现中，以下参数值得注意：脏标记传播建议使用深度优先遍历并配合已访问集合去重；对于中等规模图（节点数在千级），两阶段遍历的复杂度为 O(n)，其中 n 为需要更新的节点数；缓存策略建议默认采用生成计数器方案，只有在性能分析显示缓存命中率显著时才考虑 LRU 方案；动态依赖场景下，应在节点计算完成后立即更新其下游邻接关系。 对于需要处理长计算任务的场景，建议将计算拆分为状态机，分多次 Tick 完成更新，避免阻塞主线程。但这会引入额外的复杂性，需要权衡利弊后决定是否采用。 --- **资料来源**：Jonathan Frere, "Pushing and Pulling: Three Reactivity Algorithms" (https://jonathan-frere.com/posts/reactivity-algorithms/) ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。