Tubes是一套面向C端搭建場景，支持靈活擴(kuò)展、極致性能和高穩(wěn)定性的終端渲染解決方案，目前廣泛運(yùn)用在淘寶、天貓，包括：雙11、618會(huì)場、淘寶新人版首頁等業(yè)務(wù)場景。

介紹

響應(yīng)性數(shù)據(jù)系統(tǒng)指的是程序在使用系統(tǒng)提供的數(shù)據(jù)的同時(shí)會(huì)自動(dòng)訂閱自己所使用的數(shù)據(jù)，被訂閱的數(shù)據(jù)發(fā)生變化時(shí)使用了（訂閱了）這個(gè)數(shù)據(jù)的程序會(huì)對數(shù)據(jù)的變化做出響應(yīng)。

響應(yīng)性是 Vue.js 最具特色的特性（之前叫響應(yīng)式，Vue3給翻譯成響應(yīng)性，我認(rèn)為響應(yīng)性這個(gè)詞整挺好），不過 Tubes 的響應(yīng)性原理和 Vue.js 略有不同。

響應(yīng)性數(shù)據(jù)系統(tǒng)在Tubes中發(fā)揮的作用

Tubes 為什么需要響應(yīng)性數(shù)據(jù)系統(tǒng)，這來源于一個(gè)重要的業(yè)務(wù)問題：“如何解決會(huì)場分屏渲染問題”，站在技術(shù)視角要解決的問題是：“Tube多次執(zhí)行的設(shè)計(jì)問題”。

正在讀文章的你可能不了解Tubes體系，不清楚什么是Tube，沒關(guān)系，你可以把問題想象成：如何解決 Express.js 的中間件多次執(zhí)行、如何解決 Webpack 的Loader多次執(zhí)行。

分屏渲染指的是在搭建體系中，產(chǎn)出的頁面會(huì)先渲染首屏的模塊，再渲染次屏模塊。在Tubes體系中，從第一個(gè)Tube開始執(zhí)行，執(zhí)行到最后一個(gè)Tube則完成一次渲染（這與 Express.js 的中間件機(jī)制有點(diǎn)類似，一個(gè)請求進(jìn)來從第一個(gè) Middleware 開始執(zhí)行，執(zhí)行到最后一個(gè)Middleware結(jié)束），如下圖所示：

從第一個(gè)Tube執(zhí)行到最后一個(gè)Tube則完成一次模塊的渲染。在會(huì)場分屏渲染的場景下，通常第一輪執(zhí)行完畢表示完成了首屏模塊的渲染。那么想要渲染次屏模塊，只需要再執(zhí)行一輪Tube就可以將次屏模塊渲染出來。那么問題來了，Tube多次執(zhí)行的機(jī)制如何設(shè)計(jì)比較優(yōu)雅？

我們設(shè)計(jì)了兩種方案：“方案一：基于循環(huán)系統(tǒng)實(shí)現(xiàn)”、“方案二：基于響應(yīng)性數(shù)據(jù)系統(tǒng)實(shí)現(xiàn)”。下面我們對比下兩個(gè)方案的區(qū)別：

?  方案一：基于循環(huán)系統(tǒng)實(shí)現(xiàn)

基于循環(huán)系統(tǒng)，Tube可以一圈一圈執(zhí)行。第一圈渲染時(shí)，Tube開發(fā)者可以在內(nèi)部調(diào)用API通知 Tubes-Engine 本輪執(zhí)行完后還需要再執(zhí)行一輪。通過這樣的機(jī)制，實(shí)現(xiàn)第一圈渲染首屏模塊，第二圈渲染次屏模塊。

這里的問題是由于并不是所有Tube都需要執(zhí)行多次，因此 Tubes-Engine 需要為Tube提供一些屬性和方法（例如：當(dāng)前執(zhí)行的圈數(shù)、once方法等）方便 Tube 根據(jù) “圈數(shù)” 做一些邏輯、或者使用 once 聲明自己只需要在第一輪執(zhí)行一次，后面的其他輪次不參與執(zhí)行。

其實(shí)只有和“首屏”、“次屏”渲染邏輯強(qiáng)相關(guān)的Tube需要多次執(zhí)行（舉個(gè)例子：env tube的邏輯是初始化一些環(huán)境信息，比如是否是Android或者iOS，PC還是Mobile，這個(gè)邏輯只需要在第一輪執(zhí)行時(shí)執(zhí)行一次就可以），在基于循環(huán)系統(tǒng)的實(shí)現(xiàn)下，不需要多次執(zhí)行的Tube就需要開發(fā)者明確聲明這個(gè)Tube只需要執(zhí)行一次（就是說，如果開發(fā)者判斷自己的Tube只需要執(zhí)行一次，那么他需要為這個(gè)Tube做一些額外的處理）。

現(xiàn)在我們總結(jié)下這個(gè)方案的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)： Tubes-Engine內(nèi)部實(shí)現(xiàn)簡單（意味著不容易出錯(cuò)）

缺點(diǎn)：

1.Tube開發(fā)者需深入理解Tube運(yùn)行機(jī)制（輪圈制）以及背后為什么設(shè)計(jì)成“輪圈制”

2.每個(gè)Tube，都需要處理輪圈制相關(guān)的邏輯，例如：

只需要執(zhí)行一次的Tube：需要使用once聲明自己只需要執(zhí)行一次

需要執(zhí)行多次的Tube：需要根據(jù)圈數(shù)來判斷本輪做什么事情，以及是否需要再來下一輪并調(diào)用API通知 Tubes-Engine 再執(zhí)行一輪。

這個(gè)方案很直觀，可以解決問題。但也可以看出，該方案對Tube開發(fā)者來說使用成本很高，無論Tube是否需要多次執(zhí)行，開發(fā)者都需要深入理解背后的輪圈原理并對自己開發(fā)的Tube做相應(yīng)的判斷（是否需要多次執(zhí)行）和處理。

?  方案二：基于響應(yīng)性數(shù)據(jù)系統(tǒng)實(shí)現(xiàn)

設(shè)計(jì)之初，Tube的本質(zhì)就是一個(gè)具備 “冪等性” 的執(zhí)行單元（函數(shù)），它的一面是輸入，另一面是輸出，前一個(gè)Tube的輸出是下一個(gè)Tube的輸入，多個(gè)Tube組合在一起完成頁面渲染。

Tube是用于處理渲染的執(zhí)行單元（函數(shù)），Tubes 的設(shè)計(jì)理念是利用若干簡單的執(zhí)行單元（Tube）讓計(jì)算結(jié)果不斷漸進(jìn)，逐層推導(dǎo)復(fù)雜的運(yùn)算，而不是設(shè)計(jì)一個(gè)復(fù)雜的執(zhí)行過程?！?Tubes官網(wǎng)

具備 “冪等性” 意味著，輸入相同的情況下，輸出一定相同。也就是說輸入不變的情況下，輸出也沒有變化，因此沒有必要讓其重新執(zhí)行。只有輸入變了，才意味著輸出會(huì)變，這時(shí)候就需要重新執(zhí)行Tube使其重新計(jì)算并輸出新的結(jié)果。

方案的關(guān)鍵思路是“根據(jù)輸入輸出的變化來決定哪個(gè)Tube應(yīng)該再次執(zhí)行”，而實(shí)現(xiàn)這個(gè)能力的關(guān)鍵技術(shù)就是“響應(yīng)性數(shù)據(jù)系統(tǒng)”。

因此，基于響應(yīng)性數(shù)據(jù)系統(tǒng)指的是：只有某個(gè)Tube所使用的數(shù)據(jù)發(fā)生“變化”時(shí)，才重新“按序”執(zhí)行Tube?！鞍葱颉眻?zhí)行是指如果多個(gè)Tube都使用了同一個(gè)數(shù)據(jù)，且該數(shù)據(jù)發(fā)生了變化，那么這些 Tube 按照Tube的編排順序執(zhí)行。

例如：渲染了首屏后，“數(shù)據(jù)Tube”請求了次屏數(shù)據(jù)并將次屏數(shù)據(jù)也放入了Store中，那么這個(gè)放入數(shù)據(jù)的操作，就會(huì)觸發(fā)一個(gè)數(shù)據(jù)的 update，那么此時(shí)使用了該數(shù)據(jù)的Tube會(huì)再次執(zhí)行，且只有使用了該數(shù)據(jù)的Tube會(huì)再次執(zhí)行。再次執(zhí)行的Tube或許又會(huì)修改數(shù)據(jù)，依賴這個(gè)數(shù)據(jù)的后續(xù)Tube又會(huì)加入到“執(zhí)行隊(duì)列”中再次執(zhí)行，以此實(shí)現(xiàn)一條 “基于依賴的執(zhí)行鏈” 即：前一個(gè) Tube 修改了數(shù)據(jù)并寫入響應(yīng)性數(shù)據(jù)系統(tǒng)，后面讀取了這份數(shù)據(jù)的 Tube 會(huì)被再次執(zhí)行并將重新計(jì)算后的新數(shù)據(jù)寫入響應(yīng)性數(shù)據(jù)系統(tǒng)，而這個(gè)寫入行為又會(huì)再次觸發(fā)后面的其他 Tube 執(zhí)行，直到完成最終渲染。

現(xiàn)在我們總結(jié)下這個(gè)方案的優(yōu)缺點(diǎn)：

1. 優(yōu)點(diǎn)：

沒有對Tube增加額外負(fù)擔(dān)（無新增方法、無新增屬性、無需Tube內(nèi)部配合Tubes-Engine實(shí)現(xiàn)流程控制）

Tube對首屏次屏場景下的多次執(zhí)行無感知

只執(zhí)行需要執(zhí)行的Tube（而不是先執(zhí)行，再由中間件內(nèi)部判斷是否跳過）

2. 缺點(diǎn)： 內(nèi)部實(shí)現(xiàn)復(fù)雜（意味著容易出錯(cuò)）

基于響應(yīng)性數(shù)據(jù)系統(tǒng)，可以很智能的“挑選”出哪些Tube應(yīng)該被執(zhí)行，該方案對Tube開發(fā)者沒有任何額外負(fù)擔(dān)，而且它只執(zhí)行需要執(zhí)行的Tube，執(zhí)行效率上也更好。最終，我們選擇了使用響應(yīng)性數(shù)據(jù)系統(tǒng)。

響應(yīng)性數(shù)據(jù)系統(tǒng)的設(shè)計(jì)與原理

歷史上，為了將性能優(yōu)化到極致，Tubes 的響應(yīng)性數(shù)據(jù)系統(tǒng)的實(shí)現(xiàn)原理共設(shè)計(jì)了三個(gè)版本，由于第二個(gè)版本是第一個(gè)版本的改良版，因此本節(jié)為您詳細(xì)介紹第二個(gè)版本和第三個(gè)版本的實(shí)現(xiàn)原理。

?  經(jīng)典實(shí)現(xiàn)

當(dāng)我們研究響應(yīng)性數(shù)據(jù)系統(tǒng)的原理時(shí)，本質(zhì)上我們在研究三件事：響應(yīng)性數(shù)據(jù)、收集依賴、觸發(fā)依賴。

• 響應(yīng)性數(shù)據(jù)

響應(yīng)性數(shù)據(jù)最關(guān)鍵的兩個(gè)核心是：監(jiān)聽器、依賴存儲(chǔ)。

監(jiān)聽器

所謂的監(jiān)聽器指的是我們采用什么樣的方式攔截用戶對數(shù)據(jù)的操作，主流的實(shí)現(xiàn)方式有以下幾種：

1. Getter / Setter
2. Proxy
3. 自定義 Set/Get API

Tubes 采用第三種方式實(shí)現(xiàn)，原因是 Tube 開發(fā)者希望可以在原始數(shù)據(jù)中修改數(shù)據(jù)且不觸發(fā)響應(yīng)性，例如：

const data = this.store.get('data'); // 希望只在這里綁定依賴關(guān)系
const name = data.name; // 希望這個(gè)操作不觸發(fā)Getter
data.name = name + '!'; // 希望這個(gè)操作不觸發(fā)Setter
this.store.set('data', data); // 希望執(zhí)行到這行代碼時(shí)再統(tǒng)一觸發(fā)響應(yīng)性

Tube 開發(fā)者希望自由控制什么時(shí)候觸發(fā)響應(yīng)性，在這種場景下 Tubes 采用了自定義API的方式攔截用戶對數(shù)據(jù)的操作。

依賴存儲(chǔ)

當(dāng)監(jiān)聽器攔截到用戶對某個(gè)數(shù)據(jù)進(jìn)行操作后，需要找到這個(gè)數(shù)據(jù)對應(yīng)的“依賴”，如何找到數(shù)據(jù)對應(yīng)的“依賴”主要看“依賴”如何存儲(chǔ)，實(shí)現(xiàn)方式有很多種，傳統(tǒng)的實(shí)現(xiàn)方式比如Vue2是直接將“依賴”存在數(shù)據(jù)身上，找到了數(shù)據(jù)也就找到了這個(gè)數(shù)據(jù)對應(yīng)的“依賴”，不得不說這很方便，Tubes最初也是這樣實(shí)現(xiàn)的，如下圖所示：

如上圖所示，依賴都保存在 __dep__ 這個(gè)屬性中，而這個(gè)屬性則直接保存在數(shù)據(jù)中。

• 收集依賴

關(guān)于依賴收集，本質(zhì)上我們要解決的問題是“什么時(shí)候收集”、“收集誰”、“如何收集”、“收集到哪里”等問題。

什么時(shí)候收集

什么時(shí)候收集？答案是：“讀取數(shù)據(jù)的時(shí)候收集依賴”。當(dāng)監(jiān)聽器攔截到讀取數(shù)據(jù)時(shí)，就可以開始進(jìn)行依賴收集了。

收集誰

收集誰？回答這個(gè)問題似乎不那么簡單，事實(shí)上這個(gè)問題沒有標(biāo)準(zhǔn)答案。如果用發(fā)布&訂閱者模式來理解，那么我們收集的是“訂閱者”，當(dāng)數(shù)據(jù)發(fā)生變化時(shí)我們要通知給訂閱了這個(gè)數(shù)據(jù)的“訂閱者”，但訂閱者是誰？這取決于我們具體的需求，也就是我們希望使用響應(yīng)性數(shù)據(jù)系統(tǒng)做什么事。

在 Tubes 中，我們希望響應(yīng)性數(shù)據(jù)系統(tǒng)能幫助我們將需要再次執(zhí)行的 Tube 挑選出來，那么我們的“訂閱者”就是Tube，一旦數(shù)據(jù)發(fā)生變化，就能找到這個(gè)數(shù)據(jù)的依賴（也就是 Tube），隨后就可以將這些 Tube 發(fā)送到調(diào)度系統(tǒng)中去執(zhí)行。

在 Vue.js 中，希望響應(yīng)性數(shù)據(jù)系統(tǒng)能幫助將需要重新渲染的組件挑選出來，那么這個(gè)時(shí)候訂閱者就是組件，數(shù)據(jù)發(fā)生變化后，能找到數(shù)據(jù)的依賴（也就是組件），隨后用新數(shù)據(jù)重新渲染組件。

實(shí)際上，Tubes 中的訂閱者并不是 Tube，因?yàn)?Tube 需要支持并行執(zhí)行，如果并行執(zhí)行的 Tube 同時(shí)使用了某個(gè)數(shù)據(jù)，那么在收集他們的時(shí)候需要保持好并行Tube的數(shù)據(jù)結(jié)構(gòu)，因此在 Tubes 內(nèi)部，并行執(zhí)行的 Tube 為一組，訂閱者其實(shí)是這個(gè)小組。也就是先把 Tube 添加到這個(gè)小組，然后再把這個(gè)小組添加到依賴列表中。假設(shè)并行執(zhí)行的 Tube 只有其中一個(gè)使用了某個(gè)數(shù)據(jù)，那么這個(gè)數(shù)據(jù)的訂閱者就是一個(gè)小組，然后這個(gè)小組里面只有一個(gè) Tube，如果并行執(zhí)行的 Tube 有多個(gè)使用了某個(gè)數(shù)據(jù)，那么這個(gè)小組里面就有多個(gè) Tube。

如何收集

現(xiàn)在我們已經(jīng)知道了“什么時(shí)候收集”、“收集誰”以及“收集到哪里”，下面詳細(xì)介紹一下怎么收集，我們用一個(gè)例子來說明：

const data = ctx.store.get('a.d');

在 Tubes 中，由于同一時(shí)間只有一個(gè) Tube 在執(zhí)行，而且不存在嵌套關(guān)系，因此定位哪個(gè) Tube 中執(zhí)行了 ctx.store.get 并不困難，偽代碼如下：

function get(keypath) {
  this.ctx.tb.store.effect = effect;
  this.ctx.tb.store.tube = tube;
  const res = this.ctx.tb.store.get(keypath);
  this.ctx.tb.store.tube = null;
  this.ctx.tb.store.effect = null;
  return res;
}

上面?zhèn)未a展示了當(dāng)用戶調(diào)用 this.store.get 時(shí)，如何定位當(dāng)前正在執(zhí)行的 Tube 和 Tube 所屬的那個(gè)組（effect）。

收集到哪里

前面講響應(yīng)性數(shù)據(jù)的時(shí)候我們講依賴是直接存在數(shù)據(jù)上的，因?yàn)檫@樣方便修改數(shù)據(jù)的時(shí)候找到該數(shù)據(jù)對應(yīng)的依賴，但只將依賴保存在被修改的數(shù)據(jù)身上是不夠的。

試想一個(gè)場景，Tube A 使用了數(shù)據(jù) a.d，這時(shí)候相當(dāng)于訂閱了 a.d 這個(gè)數(shù)據(jù)，現(xiàn)在另一個(gè) Tube 修改了數(shù)據(jù) a，或者數(shù)據(jù) a.d.x 那么此時(shí) Tube A要不要響應(yīng)？答案是：要！

因此，我們得到一個(gè)結(jié)論：依賴不只是保存到目標(biāo)數(shù)據(jù)身上，還要保存到目標(biāo)數(shù)據(jù)的所有父級和所有子級中，如下圖所示：

上圖紅色圈表示需要被訂閱的數(shù)據(jù)，綠色圈表示依賴保存的位置，右側(cè)表示當(dāng) Tube 讀取 a.d 時(shí)，需要同時(shí)訂閱 a、a.d、a.d.e和a.d.f。

這里有一個(gè)細(xì)節(jié)，圖中綠色圈比我們要訂閱的數(shù)據(jù)高一個(gè)層級，這是因?yàn)閿?shù)據(jù)的最底部會(huì)出現(xiàn)基本類型的數(shù)據(jù)，而基本類型的數(shù)據(jù)是無法掛載額外屬性的，因此我們選擇將每個(gè)數(shù)據(jù)的依賴都保存在父級節(jié)點(diǎn)中。

• 讀取依賴

觸發(fā)依賴的時(shí)機(jī)是 “修改數(shù)據(jù)的時(shí)候” ，當(dāng)監(jiān)聽器攔截到用戶修改數(shù)據(jù)時(shí)，將對應(yīng)數(shù)據(jù)的依賴找到就可以了。在 Tubes 中，依賴被找到后會(huì)發(fā)送給調(diào)度系統(tǒng)執(zhí)行。

?  基于哈希表的響應(yīng)性數(shù)據(jù)系統(tǒng)

這種實(shí)現(xiàn)方式的原理和核心思想與傳統(tǒng)方式?jīng)]有太大區(qū)別，本質(zhì)上我們?nèi)栽谘芯咳拢喉憫?yīng)性數(shù)據(jù)、收集依賴、觸發(fā)依賴。

顧名思義，這種實(shí)現(xiàn)方式最大的特點(diǎn)是使用哈希表來存儲(chǔ)依賴，如下圖所示：

• 為什么使用哈希表存儲(chǔ)依賴

使用哈希表來存儲(chǔ)依賴和將依賴直接保存在數(shù)據(jù)身上的主要區(qū)別在于操作依賴的 “速度”。

前面我們講收集依賴的時(shí)候除了要將依賴保存在當(dāng)前讀取的那個(gè)數(shù)據(jù)之外還需要將依賴保存在所有父級和所有子級中。將依賴保存在所有父級中并不怎么影響性能，但將依賴保存到所有子級，這需要遍歷到每一個(gè)子級和子級的子級，如果數(shù)據(jù)非常大，那么這個(gè)遍歷的過程將非常耗時(shí)，在低端機(jī)尤其明顯。

使用哈希表來存儲(chǔ)依賴，操作依賴的速度則不受數(shù)據(jù)大小的影響，存儲(chǔ)依賴不再需要遍歷數(shù)據(jù)的每個(gè)子級，無論是保存依賴還是讀取依賴都不受數(shù)據(jù)量大小的影響，可以在一瞬間完成。

下面我們詳細(xì)介紹使用哈希表如何存儲(chǔ)和讀取依賴。

• 存儲(chǔ)依賴

使用哈希表存儲(chǔ)依賴非常簡單，只需要使用 keypath 作為 Key，值是一個(gè)列表，將依賴追加到列表中即可。這里需要注意去重的邏輯，避免將同一個(gè)依賴重復(fù)添加到列表中。一圖勝千言：

如上圖所示，當(dāng)用戶執(zhí)行 ctx.store.get('a.d') 時(shí)，直接使用 a.d 作為哈希表中的KEY將依賴追加到列表中，邏輯簡單且執(zhí)行效率高。

值得注意的是哈希表中還使用一個(gè)列表保存了依賴對應(yīng)的ID，這用于避免將重復(fù)的依賴追加到列表中。

• 讀取依賴

使用哈希表存儲(chǔ)依賴時(shí)，如何讀取某個(gè)數(shù)據(jù)對應(yīng)的依賴？

這是個(gè)好問題，當(dāng)依賴保存在數(shù)據(jù)上面時(shí)，讀取數(shù)據(jù)時(shí)只要找到了數(shù)據(jù)，就找到了數(shù)據(jù)對應(yīng)的依賴，邏輯非常簡單高效。而使用哈希表存儲(chǔ)依賴由于依賴并不保存在數(shù)據(jù)身上，所以找到了數(shù)據(jù)并不等于找到了依賴，因此我們需要一段額外的邏輯來拿到數(shù)據(jù)對應(yīng)的依賴。

我們先回顧下前面的邏輯，前面我們講當(dāng) Tube 讀取 a.d 時(shí)，需要同時(shí)訂閱 a、a.d、a.d.e和a.d.f。

也就是說，當(dāng)我們修改了某個(gè)數(shù)據(jù)時(shí)，除了該數(shù)據(jù)外，該數(shù)據(jù)的所有父級以及所有子級都需要做出響應(yīng)，現(xiàn)在這個(gè)邏輯仍然適用。因此，不難得出，當(dāng)我們修改 a.d 時(shí)，我們需要在哈希表中將 a、a.d、a.d.* 的依賴取出來，其中 a、為父級，a.d為數(shù)據(jù)本身，a.d.*為所有子級，如下圖所示：

值得注意的是，同一個(gè)KEY下面的依賴會(huì)去重， 但不同KEY之間有可能有重復(fù)的依賴，為了避免重復(fù)響應(yīng)，取出來的數(shù)據(jù)需要做一個(gè)去重處理。

• 性能提升

經(jīng)過驗(yàn)證，相比于傳統(tǒng)實(shí)現(xiàn)，使用哈希表來存儲(chǔ)依賴在低端機(jī)的性能提升尤其明顯。在維持寫入速度不變的情況下，提升讀取數(shù)據(jù)的速度 “1,349.8” 倍，在業(yè)務(wù)中的表現(xiàn)是會(huì)場的首屏速度提升452.6ms，以下是詳細(xì)數(shù)據(jù)：

1. 讀取速度：提升了1,349.8倍，Android低端機(jī)由64.79ms（10次平均值）降低為0.048ms（10次平均值）。
2. 寫入速度：維持現(xiàn)有速度不變
3. 時(shí)間復(fù)雜度：舊算法會(huì)隨著數(shù)據(jù)量大小而“增加寫入時(shí)長”，而新算法寫入速度始終保持在 0ms ~ 0.2ms 區(qū)間

1. 舊算法：讀取數(shù)據(jù)為O(N)
2. 新算法：讀取數(shù)據(jù)為O(1)

4. 對會(huì)場首屏速度的影響 （新舊算法渲染10次取平均數(shù)）：提升452.6ms

• 舊算法：2,924.7ms
• 新算法：1,917.5ms

5. 測試環(huán)境：低端機(jī)

1. 設(shè)備：紅米7
2. 系統(tǒng)：Android 9
3. 頁面：活動(dòng)中心頁面

小結(jié)

基于哈希表的響應(yīng)性數(shù)據(jù)系統(tǒng)和傳統(tǒng)實(shí)現(xiàn)在本質(zhì)上沒有區(qū)別，區(qū)別在于存儲(chǔ)依賴的方式，不同的存儲(chǔ)依賴的方式?jīng)Q定了存儲(chǔ)和讀取依賴的算法不同，不同的算法決定了執(zhí)行效率。

總結(jié)

本文詳細(xì)介紹了響應(yīng)性數(shù)據(jù)系統(tǒng)在 Tubes 中的運(yùn)用，以及響應(yīng)性數(shù)據(jù)系統(tǒng)的三種不同設(shè)計(jì)與原理，遺憾的是，該項(xiàng)目目前只針對阿里內(nèi)部開源，但一些技術(shù)思路仍可以供您學(xué)習(xí)與參考。