数据系统杂谈：React，数据一致性，计算与通信的本质

Posted 2021-09-24 csRyan

初识一致性：从一次React hooks的踩坑经历说起

让我们用具体例子来说明。对于以下的useAsynchook，你能看出哪些问题？

function useAsync(id: number) {
  const [state, setState] = useState({
    loading: true,
    data: null as null | string
  });

  useEffect(() => {
    let discarded = false;
    setState({
      loading: true,
      data: null
    });
    fakeAPI(id).then((data) => {
      if (discarded) return;
      setState({
        loading: false,
        data
      });
    });

    return () => {
      discarded = true;
    };
  }, [id]);

  return state;
}

async function fakeAPI(id: number) {
  return new Promise<string>((resolve) => {
    setTimeout(() => {
      resolve(`data for ${id}`);
    }, 1000);
  });
}

查看完整示例：
hooks-inconsistency codesandbox

为了简化例子，我们省略了错误处理

揭晓答案：在id变化以后的第一次渲染，useAsync仍会返回上一个id对应的data。这一次渲染产生了两个不一致的数据：新的id和旧的data。

很多人认为这不是一个问题，因为在这次渲染以后，useEffect会立即更新状态为loading（纠正不一致），然后下一次渲染就会返回loading的状态。

但是，这次错误渲染虽然保持的时间很短，但是仍然会产生无法预料的副作用。

在我们的完整示例中，useAsync是这样被使用的：

const [currentId, setCurrentId] = useState(1);
const { data, loading } = useAsync(currentId);
useEffect(() => {
  if (!loading && data) {
    // will trigger side effect with inconsistent id and data
    console.log("Trigger some side effect!! id:", currentId, ", data:", data);
  }
}, [currentId, loading, data]);

其中一个打印输出就是Trigger some side effect!! id: 2 , data: data for 1。说明某次副作用的执行用到了这两个不一致的数据，可能会造成无法挽回的影响。

可以看到，currentId和data被同时用于一个副作用操作中。当这两个数据出现不一致的时候，可能会造成无法挽回的影响。

在实际应用中，这两个不一致的数据会被传递给其他hooks以及子组件，你将你很难追踪定位这个问题。

最终的解决方式就是，在render阶段，就检查state与props是否不一致（props是否已经发生变化），如果是，就返回loading状态。最终代码：
hooks-inconsistency-fixed codesandbox

从这个例子，我们要吸取的教训是：

• React hooks应该立即反映props的变化，而不应等待useEffect/useLayoutEffect来纠正数据不一致

• 错误的渲染，虽然保持的时间很短（会立即在useEffect/useLayoutEffect中被纠正），但是当错误渲染被提交以后，仍然会触发意料之外的副作用，后果可能是无法挽回的。这些副作用包括：

  • useEffect、useLayoutEffect定义的副作用，使用了不一致的数据
  • DOM更新，将不一致的数据渲染到视图上。（当然，如果你立即在useLayoutEffect中纠正了数据不一致，那么用户不会看到）
  • 在错误的渲染中，初始化了一个状态，使用了不一致的数据，比如useState(() => currentId + data)。这个状态被错误地初始化以后，如果没有及时手动纠正，会造成后续更多的错误
  • 在错误的渲染中，你修改了一个ref对象，使用了不一致的数据。比如ref.current = currentId + data。和上一条类似的道理，这样的数据如果没有及时手动纠正，会造成后续更多的错误

数据一致性

数据一致性，对于React维护者、状态管理库作者，乃至任何领域的开发者而言，都是一个经常为之困扰的问题。下面我们会从比较抽象、普适的视角来讨论数据一致性。

何为数据不一致

概括来说，就是当【源数据】更新时，如果【旧的源数据、及其衍生数据和缓存】没有被及时更新，就会出现新旧数据混用的情况，导致错误的计算结果和副作用。

数据不一致的原因

数据不一致的原因是，计算是需要时间的（存储、计算、网络都是耗时的）。在这段时间内，如果【源数据】发生变化，那么在数据系统中就会同时存在多份不同版本的数据。如果没有隔离好它们，就会计算出错误的结果。

至于【源数据】发生变化的原因，通常可以总结为【外部系统的信息传播到了本数据系统】。

我们犯错的原因，往往就是潜意识认为计算不耗时间：认为在计算的时候，没有任何外部事件会发生，我们的源数据源不会发生变化。而事实却并非如此，受到了外部变化的影响。最终造成了理论结果（理想计算）和实际结果（耗时计算）的不一致。

举两个例子：

比如，当你的程序监听到文件的变更时，本质上是文件系统的数据更新传播到了本数据系统。如果此时你对旧的文件的计算还没完成，那么就要谨慎地将新旧数据区分开来，否则会产生数据不一致。

比如，React应用收到用户的输入事件时，本质上是外部世界的事件传播到了程序内的数据系统。如果此时你对过往的状态和事件还没处理完成（即上一次渲染还没完成），那么就不能盲目地让新的事件影响已有渲染，否则会产生数据不一致。事实上，React在Concurrent Mode中，就会在不同的渲染中，严格隔离事件的影响，保障数据一致性。

如何判断是否存在数据不一致

如果你的计算结果，与下述任何一个都不同，就说明存在数据不一致：

• 完全使用【旧的源数据】计算的结果。如果你的情况与它相同，说明你的结果是【正确的】，只不过【过时了】（曾经正确）
• 完全使用【新的源数据】计算的结果。如果你的情况与它相同，那么说明你的结果就是最新的、正确的

本质上就是在判断，实际计算结果是否符合理论计算结果（不耗时的理想计算），或者符合曾经的理论计算结果。

如何解决数据不一致

• 丢弃旧的源数据和衍生数据（计算结果），使用新的源数据重新计算
• 使用旧的数据完成计算（不考虑新的数据），输出结果。这个结果虽然是【过时的】，但起码是【正确的】。你先可以将这个结果输出给下游，让下游不至于【饥饿】。于此同时，你使用最新的【源数据】重新计算。这样，就能确保新旧数据不被混用（说起来简单，要做到其实很难）
• 容忍一定程度的不一致。因为在某些问题中，数据不一致是可以接受的

React中的数据一致性

React Context的核心保障之一，就是数据一致性：在同一次渲染中，从任何组件读取某个context的结果必定是相同的。如果渲染在某个地方被中断（suspend或时间片用完），后面回来继续渲染的时候，仍然读取到一样的context数据，即使在中间的这段时间，已经有新的事件更新了context的数据。React Concurrent Mode的核心工作就是将新的信息隔离在旧的渲染之外，将旧的渲染完成后提交给用户，让用户感觉到快速的响应时间。

对于React数据管理库的作者来说，要支持Concurrent Mode，就意味着不能打破React的这种信息隔离。当一个外部事件发生时（比如用户点击），这个信息只能传播给新启动的渲染，而不能传播到其他已经再进行的渲染。也就是说，必须只有新启动的渲染能感知到对应的新状态，而已有渲染必须只能感知到旧的状态。

如果打破了这种信息隔离，旧意味着，旧的渲染同时混用了新旧的数据，这个现象被称为"tearing"：
dai-shi/will-this-react-global-state-work-in-concurrent-mode: Checking tearing in React concurrent mode 项目就测试了多个状态管理库的tearing情况。能完美避免tearing的状态管理库并不多。由此可见，设计一致的数据系统并不是一件容易的事情。

计算的本质是通信

数据系统的本质是通信

上面已经提到，在数据系统中，解决数据不一致的通常原则是，【过时的结果】总比【错误的结果】要好。这是为什么呢？

因为【过时】只不过是信息传播时延的体现。哪怕是电磁波通信都有时延呢，对吧？信息传播的时延是注定存在的（并且大于等于光速时延），因此，数据系统【具有时延地】输出计算结果，是再正常不过的自然现象。

因此，当数据系统将【过时但正确的计算结果】传播给下游消费者，其实本质上就是一种有时延的通信而已。时延是注定存在的，下游消费者自然会欣然接受。

用这个视角仔细观察生活中的日常现象，你会发现通信无处不在，通信时延也无处不在。

计算的本质也是通信

既然数据系统的本质是通信，那么进一步思考，组成数据系统的各个环节（存储、计算、网络）也都应该是通信。对于存储和网络，相信大家都可以理解。但是为什么计算也可以理解为一种通信？

首先，我们要理解通信是什么。运动和通信是一体两面。从微观上看，通信必定对应着一种运动。（要么是粒子的运动，要么是波的运动）

人类通信发展的历史，从声波通信、视觉通信，发展到快马送信，再到电报通信，最后到无线通信，都没有脱离运动的微观本质。它们依次是声波、电磁波、物质分子、电子、电磁波的运动。

而计算，从微观上讲，就是信号从一条【信息通路】的输入端传播到了输出端。计算的结果就是粒子运动的结果。
比如，逻辑电路的工作原理归结于电子的运动。当我们在使用逻辑电路进行计算的时候，只不过是将电子注入输入端，然后从输出端观察电子运动的结果而已。

这不就是一种通信吗？计算的本质是信息的传播（即通信），而它们的本质都是运动。

让我们用通信的视角来进一步思考计算的本质：

• 设计计算机器，本质上就是将我们的知识，设计成一条【信息通路】。在使用的时候，就将输入信号注入输入端，让信息传播，然后在输出端观察到信息传播的结果。
• 设计逻辑电路、甚至芯片的过程，本质上就是在将我们的知识设计成复杂的【信息通路】，控制粒子的运动（信息的传播）。
• 编程，其实本质就是在设计一种机器。程序就是对一种机器的描述(参考sicp 4.1.5节)。而通用计算机，就根据我们的程序，将自己模拟成程序所描述的那台机器。因此，归根结底，我们的每一行代码，其实都在决定电子的【信息通路】。
• 算盘，其实也是人类设计的一种计算机器，它的工作原理就是算珠在【信息通路】上的运动。

其他类型的运动，如果足够可控，也可以用来实现计算。比如，光子计算机，就是利用了光子的运动来实现逻辑电路。

任何一个数据系统，包括其中的存储、计算、网络，本质上都是信息的传播（通信）。【输出过时的结果】只不过是通信时延的体现，是理所当然的事情，更无法避免。

因此，我们要避免的不是通信时延（当然我们应该尽力降低它），而是：

• 从计算的角度来说，我们要避免的是混用不同版本的数据，导致数据不一致的结果（参考上面的“如何判断是否存在数据不一致”小节）。
• 从通信的角度来说，我们要避免的是在通信过程中新旧的信息相互干涉，形成噪声。

希望这篇文章能给你提供一个全新的视角。