采集時序數(shù)據(jù)的另一個好處，就是能夠通過編程使你的應用生成測量數(shù)據(jù)，從而可以建立安全、精密的反饋循環(huán)，這方面有很多有用的例子。
在云計算中，啟用新的實例只需要給提供者發(fā)一條簡單的API調(diào)用即可，但要想知道什么時候應該啟動更多的實例或撤銷正在運行的實例，就會很麻煩。如果基于采集的資源使用情況來判斷啟用撤銷的話，就會容易得多，這是測量數(shù)據(jù)用做反饋機制的一種通例。
我在Flickr，有一個大型項目，使用了這種反饋機制，事實證明，非常有用。

2007年，Yahoo!決定關(guān)掉Yahoo!!Photos計劃很簡單:通知Yahoo!Photos的用戶，這個服務將被關(guān)閉，用戶可以自己選擇，將自己的照片連同元數(shù)據(jù)一起轉(zhuǎn)移到其他的服務，包括非Yahoo!!的服務，像Shutterfly和KodakGallery，F(xiàn)lickr也是選項之一。
為這個項目做出容量評估將是一件苦差事。盡管有一些測量數(shù)器據(jù)，用上載頻度、片大小及其他因素指述了Yahoo!Photos的典型用戶，但有多少用戶會選擇Flickr，即使選擇了Flickr，用戶的使用模式又會如何變化，我們心里仍然沒底。我們談論的是一項已經(jīng)超過10年的照片存儲服務，將會有巨量的數(shù)括，而且這么大的空同會在很短的時間內(nèi)消耗掉。不用講得太精確，我告訴你，2009年后期，F(xiàn)ick每天用掉大約12TB的存儲客量。從Yahoo!Photos到Flickr的遷移，在2007年持續(xù)了一段不長的時間，每天消耗的存空間是這個數(shù)的兩倍還多。
在在備遷移的過程中，基于對遷移的評估以及現(xiàn)有的Yahoo!Photos數(shù)器，我們對存需求做了最好的估計，并給出了一個寬松的安全系統(tǒng)，確保遷移結(jié)束之前，不會出現(xiàn)存空間不夠的情況。我們能想到的每件事情，都有測量數(shù)據(jù):
● 遷移的賬戶
● 遷移的照片
● 處理的照片
● 遷移隊列大小
● 磁盤空間消耗量
對選擇遷移到Flickr的用戶，開始遷移過程，并進行觀察
我直接聯(lián)到有意思的部分來說吧:即使微了如此謹慎的估計，我們還是錯了，錯大了。雖然做了研究，對存豬容量做了精心的評估，想遷近移到Fick來的人還是超出了我們的預期。要把想遷移到Flickr來的人的Yhoo!Photos數(shù)據(jù)都近移過來的話，我們部看的存豬空間都會用完。要么增加存豬，要么Flickr停止上載片。
調(diào)天地，由于測量數(shù)據(jù)能夠追蹤磁を請耗，我們很快意識到了這點，但卻受限于采購時間表。重要的是盡快購買、安裝、配置、部署更多存造，以免用完現(xiàn)有存。部著更多空間與遷移進程之間展開了一場競賽，
為了解釋我們是如何通過測量數(shù)據(jù)反轉(zhuǎn)危為安的，要先介紹一下遷移過程是如何進行的:
1.告知用戶，將關(guān)閉Yahoo!Photos服務，用戶可以從列表中選擇遷移到哪里。假如選擇Flickr的話，該用戶賬號就進人遷移隊列。
2.一旦用戶的遷移任務進入隊列，則則鎖定該用戶的Yahoo!Photos賬號，防止用戶進行修改。現(xiàn)在Yahoo!Photos和Flickr之間進行API對API的通信，以獲取要遷移的照片數(shù)據(jù)。
3.Flickr獲取并處理Yahoo!Photos賬號的照片及其元數(shù)據(jù)。
4.將Yahoo!Photos賬號寫人Flickr存儲和數(shù)據(jù)庫。
遷移完成后，開放Flickr這邊的賬號，通知用戶可以使用遷移過來的Flickr新賬號了。單個用戶的遷移并不需要很長時間，但用戶量很大，所以還是花了不少時間。遷移過程基本上就是一個大規(guī)模的異步過程，每個異步過程包括創(chuàng)建Flickr新賬號和批量上載照片。
由于知道遷移要消耗多少存儲、“有機”(非遷移)增長要消耗多少存儲，即使估計不足的話，也可以預測出還能夠支持的天數(shù)。我們下了一個龐大的訂單，來購買存儲，并開始計時。確認了發(fā)貨和安裝日期，這樣我們就知道這些存儲什么時候能夠在數(shù)據(jù)中心上架以及需要多久才能投入使用。
因為使用Ganglia采集數(shù)據(jù)，3行腳本代碼就可以計算出存儲的消耗率，然后將這個數(shù)字傳給負責遷移的API進程。照片是存儲在分布于美國各地的若干個數(shù)據(jù)中心的，要確保API進程能夠遠程獲得這個值，并檢查正在遷移數(shù)據(jù)的所有數(shù)據(jù)中心。我們修改了API的處理過程，以便觀察存儲消耗的速率。如果在過去的一小時存儲的消耗率大于維持到新存儲上線那天的消耗率，則降低對排隊等待遷移的賬號的處理速度，反之，則加快處理速度。前面列出的步驟中，我們在步驟2和步驟3之間插入了一個檢查當前存儲消耗率的步驟。
因為我們會根據(jù)存儲的消耗率調(diào)整遷移的速度，進入隊列的賬號可能會等待更長的時間。減慢處理過程也是一個不得已的折中，既要保證遷移的順利進行，又要不影響Flickr的當前業(yè)務。
最終，遷移順利完成，沒有發(fā)生存儲空間用光的情況。事后看來，我們的估計是有偏差的，但并沒有當初想的那么大。遷移開始時的高峰使我們擔心存儲會用光，所以馬上部署了更多的存儲。但隨著漸漸接近原來的存儲極限，進入遷移隊列的用戶也慢慢減少了
這個故事說明，將分布在全國多個地點的網(wǎng)站建設測量數(shù)據(jù)采集系統(tǒng)納入反饋循環(huán)，能夠?qū)B級照片數(shù)據(jù)從Yahoo!Photos安全地遷移到Flickr，同日時基本不影響兩者的正常使用。

文章標題：怎么使用測量數(shù)據(jù)建立加載一反饋機制？
網(wǎng)頁路徑：http://jinyejixie.com/news/151359.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、全網(wǎng)營銷推廣、品牌網(wǎng)站建設、響應式網(wǎng)站、Google、網(wǎng)站維護

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)