[2021-6-15] 异步I/O:用户体验

[HJY-xh]

异步的概念之所以首先在Web2.0中火起来，是因为在浏览器中JavaScript在单线程上执行，而且它还与UI渲染共用一个线程。这意味着JavaScript在执行的时候UI渲染和和相应是处于停滞状态的。《高性能JavaScript》一书中曾经总结过，如果脚本的执行时间超过100毫秒，用户就会感觉到页面卡顿，意味网页停止响应。

在B/S模型中，网络速度的限制给网页的实施体验造成很大麻烦。如果网页临时需要获取一个网络资源，通过同步的方式获取，那么JavaScript则需要等待资源完全从服务器端获取后才能继续执行，这期间UI将停顿，不响应用户的交互行为。可以想象，这样的用户体验将会多差。而采用异步请求，在下载资源期间，JavaScript和UI的执行都不会处于等待状态，可以继续响应用户的交互行为，给用户一个鲜活的页面。

同理，前端通过异步可以消除掉UI阻塞的现象，但是前端获取资源的速度也取决于后端的响应速度，假如一个资源来自于两个不同位置的数据的返回，第一个资源需要M毫秒的耗时，第二个资源需要N毫秒的耗时。如果采用同步的方式，代码大致如下：

// 消费时间M
getData('from_db');
// 消费时间N
getData('from_remote_api');

但是如果采用异步方式，第一个资源的获取并不会阻塞第二个资源，也即第二个资源的请求，并不依赖第一个资源的结束。这样就能享受到并发的优势，代码如下：

getData('from_db'， function(result){
// 消费时间M
});

getData('from_remote_api'， function(result){
// 消费时间N
});

对比两者的时间总消耗，前者为M+N，后者为max(M，N）

随着应用复杂性的增加，情景将会变成M+N+...和max(M，N，...），同步与异步的优劣将会凸显出来。另一方面，随着网站或应用不断膨胀，数据将会分布到多台服务器上，分布式将会是常态。分布也以为这M与N的值会线性增长，这也会放大异步和同步在性能方面的差异。

还可以了解一下从CPU一级缓存到网络的数据访问所需要的开销，这里不提。

这就是异步I/O在Node中如此盛行。

I/O是昂贵的，分布式I/O是更昂贵的。

[HJY-xh]

相关Issue：https://github.com/HJY-xh/plantTrees/issues/315