課件4—第二章 Google云計(jì)算原理與應(yīng)用(3).ppt

電子工業(yè)出版社 云計(jì)算 第二版 配套課件 解放軍理工大學(xué)劉鵬教授主編華東交通大學(xué)劉鵬制作 第2章Google云計(jì)算原理與應(yīng)用 云計(jì)算 第二版 購買網(wǎng)址 當(dāng)當(dāng)網(wǎng)京東商城 姊妹力作 實(shí)戰(zhàn)Hadoop 購買網(wǎng)址 當(dāng)當(dāng)網(wǎng)京東商城 提綱 Google文件系統(tǒng)GFS 分布式數(shù)據(jù)處理MapReduce 分布式鎖服務(wù)Chubby 分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable 分布式存儲(chǔ)系統(tǒng)Megastore 大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper Google應(yīng)用程序引擎 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 在互聯(lián)網(wǎng)的應(yīng)用中 為了達(dá)到好的可擴(kuò)展性 常常會(huì)采用NoSQL存儲(chǔ)方式 但是從應(yīng)用程序的構(gòu)建方面來看 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫又有著NoSQL所不具備的優(yōu)勢 Google設(shè)計(jì)和構(gòu)建了用于互聯(lián)網(wǎng)中交互式服務(wù)的分布式存儲(chǔ)系統(tǒng)Megastore 該系統(tǒng)成功的將關(guān)系型數(shù)據(jù)庫和NoSQL的特點(diǎn)與優(yōu)勢進(jìn)行了融合 設(shè)計(jì)目標(biāo)及方案選擇 可用性 實(shí)現(xiàn)了一個(gè)同步的 容錯(cuò)的 適合遠(yuǎn)距離傳輸?shù)膹?fù)制機(jī)制 引入Paxos算法并對其做出一定的改進(jìn)以滿足遠(yuǎn)距離同步復(fù)制的要求 可擴(kuò)展性 借鑒了數(shù)據(jù)庫中數(shù)據(jù)分區(qū)的思想 將整個(gè)大的數(shù)據(jù)分割成很多小的數(shù)據(jù)分區(qū) 每個(gè)數(shù)據(jù)分區(qū)連同它自身的日志存放在NoSQL數(shù)據(jù)庫中 具體來說就是存放在Bigtable中 設(shè)計(jì)目標(biāo) 一種介于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和NoSQL之間的存儲(chǔ)技術(shù) 盡可能達(dá)到高可用性和高可擴(kuò)展性的統(tǒng)一 數(shù)據(jù)分區(qū)和復(fù)制 數(shù)據(jù)分區(qū)和復(fù)制 Megastore中 這些小的數(shù)據(jù)分區(qū)被稱為實(shí)體組集 EntityGroups 每個(gè)實(shí)體組集包含若干實(shí)體組 EntityGroup 相當(dāng)于分區(qū)中表的概念 而一個(gè)實(shí)體組中又包含很多的實(shí)體 Entity 相當(dāng)于表中記錄的概念 從圖中還可以看出單個(gè)實(shí)體組支持ACID語義 實(shí)體組集之間只具有比較松散的一致性 每個(gè)實(shí)體組都通過復(fù)制技術(shù)在數(shù)據(jù)中心中保存若干數(shù)據(jù)副本 這些實(shí)體組及其副本都存儲(chǔ)在NoSQL數(shù)據(jù)庫 Bigtable 中 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 Megastore數(shù)據(jù)模型 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫是通過連接 Join 來滿足用戶的需求的 但是就Megastore而言 這種數(shù)據(jù)模型是不合適的 主要有以下三個(gè)原因 1 對于高負(fù)載的交互式應(yīng)用來說 可預(yù)期的性能提升要比使用一種代價(jià)高昂的查詢語言所帶來的好處多 2 Megastore所面對的應(yīng)用是讀遠(yuǎn)多于寫 因此好的選擇是將讀操作所需要做的工作盡可能地轉(zhuǎn)移到寫操作上 3 在Bigtable這樣的鍵 值存儲(chǔ)系統(tǒng)中存儲(chǔ)和查詢級聯(lián)數(shù)據(jù) HierarchicalData 是很方便的 Megastore數(shù)據(jù)模型怎么設(shè)計(jì) Google設(shè)計(jì)了一種能夠提供細(xì)粒度控制的數(shù)據(jù)模型和模式語言 同關(guān)系型數(shù)據(jù)庫一樣 Megastore的數(shù)據(jù)模型是在模式 schema 中定義的且是強(qiáng)類型的 stronglytyped 每個(gè)模式都由一系列的表 tables 構(gòu)成 表又包含有一系列的實(shí)體 entities 每實(shí)體中包含一系列屬性 properties 屬性是命名的且具有類型 這些類型包括字符型 strings 數(shù)字類型 numbers 或者Google的ProtocolBuffers 這些屬性可以被設(shè)置成必須的 required 可選的 optional 或者可重復(fù)的 repeated 即允許單個(gè)屬性上有多個(gè)值 數(shù)據(jù)模型實(shí)例 照片共享服務(wù)數(shù)據(jù)模型實(shí)例 圖中表Photo就是一個(gè)子表 因?yàn)樗暶髁艘粋€(gè)外鍵 User則是一個(gè)根表 一個(gè)Megastore實(shí)例中可以有若干個(gè)不同的根表 表示不同類型的實(shí)體組集 圖中實(shí)例還可以看到三種不同屬性設(shè)置 既有必須的 如user id 也有可選的 如thumbnail url 值得注意的是Photo中的可重復(fù)類型的tag屬性 這也就意味著一個(gè)Photo中允許同時(shí)出現(xiàn)多個(gè)tag屬性 索引 Index Megastore索引分成兩大類 局部索引 localindex 和全局索引 globalindex 局部索引定義在單個(gè)實(shí)體組中 作用域僅限于單個(gè)實(shí)體組 如PhotosByTime 全局索引則可以橫跨多個(gè)實(shí)體組集進(jìn)行數(shù)據(jù)讀取操作 如PhotosByTag Megastore還提供了一些額外的索引特性 STORING子句 STORINGClause 可重復(fù)的索引 RepeatedIndexes 內(nèi)聯(lián)索引 InlineIndexes Bigtable中數(shù)據(jù)存儲(chǔ)情況 表中不難看出 Bigtable的列名實(shí)際上是表名和屬性名結(jié)合在一起得到 不同表中實(shí)體可存儲(chǔ)在同一個(gè)Bigtable行中 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 Megastore中的事務(wù)及并發(fā)控制 Megastore三種方式的讀 分別是current snapshot和inconsistent 其中current讀和snapshot讀總是在單個(gè)實(shí)體組中完成 對于snapshot讀 系統(tǒng)取出已知的最后一個(gè)完整提交的事務(wù)的時(shí)間戳 接著從這個(gè)位置讀數(shù)據(jù) inconsistent讀忽略日志的狀態(tài)直接讀取最新的值 Megastore中的事務(wù)及并發(fā)控制 Megastore事務(wù)中的寫操作采用了預(yù)寫式日志 Write aheadLog 一個(gè)寫事務(wù)總是開始于一個(gè)current讀以便確認(rèn)下一個(gè)可用的日志位置 提交操作將數(shù)據(jù)變更聚集到日志 接著分配一個(gè)比之前任意一個(gè)都高的時(shí)間戳 然后使用Paxos將數(shù)據(jù)變更加入到日志中 協(xié)議使用了樂觀并發(fā) OptimisticConcurrency 盡管可能有多個(gè)寫操作同時(shí)試圖寫同一個(gè)日志位置 但只會(huì)有1個(gè)成功 讀 獲取最后一次提交的事務(wù)的時(shí)間戳和日志位置 完整事務(wù)周期 應(yīng)用邏輯 從Bigtable讀取且聚集數(shù)據(jù)到日志入口 提交 使用Paxos達(dá)到一致 將個(gè)入口追加到日志 生效 將數(shù)據(jù)更新到Bigtable中的實(shí)體和索引 清除 清理不再需要的數(shù)據(jù) Megastore中的事務(wù)機(jī)制 消息隊(duì)列機(jī)制 消息能夠橫跨實(shí)體組 每個(gè)消息都有一個(gè)發(fā)送和接收實(shí)體組 如果兩個(gè)實(shí)體組是不同的 則傳輸將是異步 特點(diǎn) 規(guī)模 聲明一個(gè)隊(duì)列后可以在其他所有的實(shí)體組上創(chuàng)建一個(gè)收件箱 支持兩階段提交 增加競爭風(fēng)險(xiǎn) 不鼓勵(lì)使用 Megastore中的事務(wù)機(jī)制 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 Megastore的基本架構(gòu) Megastore中三種副本 完整副本 Bigtable中存儲(chǔ)完整的日志和數(shù)據(jù) 見證者副本 在Paxos算法執(zhí)行過程中無法產(chǎn)生一個(gè)決議時(shí)參與投票 只讀副本 讀取最近過去某一個(gè)時(shí)間點(diǎn)一致性數(shù)據(jù) Megastore的基本架構(gòu) Megastore中提供快速讀 FastReads 和快速寫 FastWrites 機(jī)制 快速讀 如果讀操作不需要副本之間進(jìn)行通信即可完成 那么讀取的效率必然相對較高 利用本地讀取 LocalReads 實(shí)現(xiàn)快速讀 能夠帶來更好的用戶體驗(yàn)及更低的延遲 確保快速讀成功的關(guān)鍵是保證選擇的副本上數(shù)據(jù)是最新的 為了達(dá)到這一目標(biāo) 引入了協(xié)調(diào)者的概念 協(xié)調(diào)者是一個(gè)服務(wù) 該服務(wù)分布在每個(gè)副本的數(shù)據(jù)中心里面 它的主要作用就是跟蹤一個(gè)實(shí)體組集合 協(xié)調(diào)者的狀態(tài)是由寫算法來保證 快速寫 Megastore采用了一種在主 從式系統(tǒng)中常用的優(yōu)化方法 如果一次寫成功 那么下一次寫的時(shí)候就跳過準(zhǔn)備過程 直接進(jìn)入接受階段 Megastore沒有使用專門的主服務(wù)器 而是使用leaders leader主要是來裁決哪個(gè)寫入的值可以獲取0號(hào)提議 優(yōu)化 提交值最多的位置附近選擇一副本作為leader 客戶端 網(wǎng)絡(luò)及Bigtable的故障都會(huì)導(dǎo)致一個(gè)寫操作處于不確定的狀態(tài) 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 復(fù)制的日志 預(yù)寫式日志 當(dāng)日志有不完整的前綴時(shí)我們就稱一個(gè)日志副本有 缺失 Holes 圖中0 99的日志位置已經(jīng)被全部清除 100的日志位置被部分清除 101的日志位置被全部副本接受 102的日志位置被 獲得 103的日志位置被副本A和C接受 副本B則留下了一個(gè) 缺失 104的日志位置則未達(dá)到一致性 數(shù)據(jù)讀取 數(shù)據(jù)讀取 數(shù)據(jù)讀取過程 本地查詢 QueryLocal 發(fā)現(xiàn)位置 FindPosition 本地讀取 LocalRead 多數(shù)派讀取 MajorityRead 追趕 Catchup Paxos將會(huì)促使絕大多數(shù)副本達(dá)成一個(gè)共識(shí)值 達(dá)到一種分布式一致狀態(tài) 驗(yàn)證 Validate 查詢數(shù)據(jù) QueryData 數(shù)據(jù)寫入 數(shù)據(jù)寫入 數(shù)據(jù)寫入完整過程 1 接受leader 請求leader接受值作為0號(hào)提議 快速寫方法 若成功 跳至步驟 3 2 準(zhǔn)備 將值替換成擁有最高提議號(hào)的那個(gè)值 3 接受 請求剩余的副本接受該值 如果大多數(shù)副本拒絕這個(gè)值 返回步驟 2 4 失效 將不接受值的副本上的協(xié)調(diào)者進(jìn)行失效操作 5 生效 將值的更新在盡可能多的副本上生效 如果選擇的值和原來提議的有沖突 返回一個(gè)沖突錯(cuò)誤 協(xié)調(diào)者的可用性 協(xié)調(diào)者在系統(tǒng)中是比較重要的 協(xié)調(diào)者的進(jìn)程運(yùn)行在每個(gè)數(shù)據(jù)中心 每次的寫操作中都要涉及協(xié)調(diào)者 因此協(xié)調(diào)者的故障將會(huì)導(dǎo)致系統(tǒng)的不可用 Megastore使用了Chubby鎖服務(wù) 為了處理請求 一個(gè)協(xié)調(diào)者必須持有多數(shù)鎖 一旦因?yàn)槌霈F(xiàn)問題導(dǎo)致它丟失了大部分鎖 協(xié)調(diào)者就會(huì)恢復(fù)到一個(gè)默認(rèn)保守狀態(tài) 除了可用性問題 對于協(xié)調(diào)者的讀寫協(xié)議必須滿足一系列的競爭條件 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 可用性分布情況 可用性分布情況 Megastore在Google中已經(jīng)部署和使用了若干年 有超過100個(gè)產(chǎn)品使用Megastore作為其存儲(chǔ)系統(tǒng) 從圖中可以看出 絕大多數(shù)產(chǎn)品具有極高的可用性 99 999 這表明Megastore系統(tǒng)的設(shè)計(jì)是非常成功的 基本達(dá)到了預(yù)期目標(biāo) 產(chǎn)品延遲情況分布 應(yīng)用程序的平均讀取延遲在萬分之一毫秒之內(nèi) 平均寫入延遲在100至400毫秒之間 避免Megastore的性能下降 可采取以下三種應(yīng)對方法 可能結(jié)合使用 1 重新選擇路由使客戶端繞開出現(xiàn)問題的副本 2 將出現(xiàn)問題副本上的協(xié)調(diào)者禁用 確保問題的影響降至最小 3 禁用整個(gè)副本 平均延遲的分布 需要指出 Megastore已經(jīng)是Google相對過時(shí)的存儲(chǔ)技術(shù) Google目前正在使用的存儲(chǔ)系統(tǒng)是Spanner架構(gòu) Spanner的設(shè)計(jì)目標(biāo)是能夠控制一百萬到一千萬臺(tái)服務(wù)器 Spanner最強(qiáng)大之處在于能夠在50毫秒之內(nèi)為數(shù)據(jù)傳遞提供通道 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) 用戶將一個(gè)關(guān)鍵字通過Google的輸入框傳到Google的后臺(tái) 在我們看來很簡單的一次搜索實(shí)際上涉及了眾多Google后臺(tái)子系統(tǒng) 這些子系統(tǒng)的運(yùn)行狀態(tài)都需要進(jìn)行監(jiān)控 廣泛可部署性 不間斷的監(jiān)控 監(jiān)控系統(tǒng)設(shè)計(jì)兩個(gè)基本要求 設(shè)計(jì)目標(biāo) 03 02 01 廣泛可部署性的必然要求 監(jiān)控系統(tǒng)的開銷越低 對于原系統(tǒng)的影響就越小 系統(tǒng)的開發(fā)人員也就越愿意接受這個(gè)監(jiān)控系統(tǒng) Google的服務(wù)增長速度是驚人的 設(shè)計(jì)出的系統(tǒng)至少在未來幾年里要能夠滿足Google服務(wù)和集群的需求 如果監(jiān)控系統(tǒng)的使用需要程序開發(fā)人員對其底層的一些細(xì)節(jié)進(jìn)行調(diào)整才能正常工作的話 這個(gè)監(jiān)控系統(tǒng)肯定不是一個(gè)完善的監(jiān)控系統(tǒng) 低開銷 應(yīng)用層透明 可擴(kuò)展性 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) 基本概念 圖中 用戶發(fā)出請求X 前端A發(fā)現(xiàn)該請求的處理需要涉及服務(wù)器B和服務(wù)器C 因此A又向B和C發(fā)出兩個(gè)RPC 遠(yuǎn)程過程調(diào)用 B收到后立刻做出響應(yīng) 但是C在接到后發(fā)現(xiàn)它還需要調(diào)用服務(wù)器D和E才能完成請求X 因此C對D和E分別發(fā)出了RPC D和E接到后分別做出了應(yīng)答 收到D和E的應(yīng)答之后C才向A做出響應(yīng) 在接收到B和C的應(yīng)答之后A才對用戶請求X做出一個(gè)應(yīng)答X 在監(jiān)控系統(tǒng)中記錄下所有這些消息不難 如何將這些消息記錄同特定的請求 本例中的X 關(guān)聯(lián)起來才是分布式監(jiān)控系統(tǒng)設(shè)計(jì)中需要解決的關(guān)鍵性問題之一 典型分布式系統(tǒng)的請求及應(yīng)答過程 方案一黑盒 BlackBox 方案 方案比較輕便 但在消息關(guān)系判斷過程中 主要是利用一些統(tǒng)計(jì)學(xué)知識(shí)來進(jìn)行推斷 有時(shí)不是很準(zhǔn)確 方案二基于注釋的方案 利用應(yīng)用程序或中間件給每條記錄賦予一個(gè)全局性的標(biāo)示符 借此將相關(guān)消息串聯(lián)起來 Google最終選擇 基本概念 Dapper監(jiān)控系統(tǒng)中三個(gè)基本概念 監(jiān)控樹 TraceTree 區(qū)間 Span 和注釋 Annotation 圖示是一個(gè)典型的監(jiān)控樹 實(shí)際上就是一個(gè)同特定事件相關(guān)的按照一定的規(guī)律以樹的形式組織起來所有消息 每一個(gè)節(jié)點(diǎn)稱為一個(gè)區(qū)間 一條記錄 所有記錄聯(lián)系在一起就構(gòu)成了對某個(gè)事件的完整監(jiān)控 每個(gè)區(qū)間包括如下的內(nèi)容 區(qū)間名 SpanName 區(qū)間id Spanid 父id Parentid 和監(jiān)控id Traceid 監(jiān)控樹 監(jiān)控id圖中并沒有列出 一棵監(jiān)控樹中所有區(qū)間的監(jiān)控id相同 隨機(jī)分配且唯一 區(qū)間Helper Call的詳細(xì)信息 圖中區(qū)間包含來自客戶端的注釋信息 ClientSend ClientRecv 和 也包含來自服務(wù)器端的注釋信息 ServerRecv foo 和 ServerSend 除 foo 是用戶自定義的注釋外 其他的注釋信息都是和時(shí)間相關(guān)的信息 Dapper不但支持用戶進(jìn)行簡單的文本方式的注釋 還支持鍵 值對方式的注釋 基本概念 監(jiān)控信息的匯總 監(jiān)控信息匯總 監(jiān)控信息匯總 1 將區(qū)間的數(shù)據(jù)寫入到本地的日志文件 2 所有機(jī)器上的本地日志文件匯集 3 匯集后的數(shù)據(jù)寫入到Bigtable存儲(chǔ)庫中 監(jiān)控?cái)?shù)據(jù)匯總是單獨(dú)進(jìn)行的 而不是伴隨系統(tǒng)對用戶的應(yīng)答一起返回的 如此選擇主要原因 內(nèi)置的匯總方案 監(jiān)控?cái)?shù)據(jù)隨RPC應(yīng)答頭返回 會(huì)影響網(wǎng)絡(luò)動(dòng)態(tài) 內(nèi)置的匯總方案需要保證所有的RPC都是完全嵌套 安全問題 應(yīng)用層注釋提供一種方便的選擇機(jī)制 Opt inMechanism 應(yīng)用程序開發(fā)者可以將任何對后期分析有益的數(shù)據(jù)和區(qū)間關(guān)聯(lián)起來 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) Dapper三個(gè)設(shè)計(jì)目標(biāo)中 實(shí)現(xiàn)難度最大的是 應(yīng)用層透明 怎么實(shí)現(xiàn)應(yīng)用層透明 輕量級的核心功能庫 二次抽樣技術(shù) 輕量級核心功能庫 將Dapper的核心監(jiān)控實(shí)現(xiàn)限制在一個(gè)由通用線程 UbiquitousThreading 控制流 ControlFlow 和RPC代碼庫 RPCLibraryCode 組成的小規(guī)模庫基礎(chǔ)上 其中最關(guān)鍵的代碼基礎(chǔ)是基本RPC 線程和控制流函數(shù)庫的實(shí)現(xiàn) 主要功能是實(shí)現(xiàn)區(qū)間創(chuàng)建 抽樣和在本地磁盤上記錄日志 二次抽樣技術(shù) 第一次抽樣 實(shí)踐中 設(shè)計(jì)人員發(fā)現(xiàn)當(dāng)抽樣率低至1 1024時(shí)也能夠產(chǎn)生足夠多的有效監(jiān)控?cái)?shù)據(jù) 即在1024個(gè)請求中抽取1個(gè)進(jìn)行監(jiān)控也是可行的 從而可以捕獲有效數(shù)據(jù) 第二次抽樣 發(fā)生在數(shù)據(jù)寫入Bigtable前 具體方法是將監(jiān)控id散列成一個(gè)標(biāo)量z 0 z 1 如果某個(gè)區(qū)間的z小于事先定義好的匯總抽樣系數(shù) 則保留這個(gè)區(qū)間并將它寫入Bigtable 否則丟棄 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) Dapper存儲(chǔ)API Dapper的 存儲(chǔ)API 簡稱為DAPI 提供了對分散在區(qū)域Dapper存儲(chǔ)庫 DEPOTS 的監(jiān)控記錄的直接訪問 一般來說 有以下三種方式可以對這些記錄進(jìn)行訪問 1 監(jiān)控id訪問 AccessbyTraceid 利用全局唯一的監(jiān)控id直接訪問所需的監(jiān)控?cái)?shù)據(jù) 2 塊訪問 BulkAccess 借助MapReduce對數(shù)以十億計(jì)的Dapper監(jiān)控?cái)?shù)據(jù)的并行訪問 3 索引訪問 IndexedAccess Dapper存儲(chǔ)庫支持單索引 SingleIndex 根據(jù)不完全統(tǒng)計(jì) 目前大約有三個(gè)基于DAPI的持久應(yīng)用程序 八個(gè)額外的基于DAPI的按需分析工具及大約15 20個(gè)使用DAPI框架構(gòu)建的一次性分析工具 Dapper用戶界面 1 選擇監(jiān)控對象 起止時(shí)間 區(qū)分監(jiān)控模式的信息及一個(gè)衡量開銷的標(biāo)準(zhǔn) 2 用戶對這