不要立即檢查剛做過的事情,也不要立即讀剛寫過的數(shù)據(jù)。絕對不要為了驗證而立即讀剛寫過的數(shù)據(jù)。為了近期內(nèi)的運維需要,可以把數(shù)據(jù)存儲在本地或分布式的緩存中。驗證工作相對于不太可能出現(xiàn)的故障來說成本更高。這種活動有悖于有效擴展的需求。
絕對不要為了驗證數(shù)據(jù)而立即讀剛寫入的數(shù)據(jù),而要讀并處理與寫操作相關(guān)的錯誤。把數(shù)據(jù)存儲在本地可以避免對剛剛寫入的數(shù)據(jù)的其他讀操作。
木匠有句名言:“量兩次,鋸一次。”你可能從中學(xué)的木工老師那里聽過這句話一他可能還缺了根手指。拋開少手指這事不說,這句名言還是很有道理的,正所謂實踐出真知。最好在切割前驗證測量的準(zhǔn)確度,因為錯誤的測量結(jié)果會導(dǎo)致生產(chǎn)浪費,例如切出一塊大小不對的木板。我們當(dāng)然不會那么做。然而,我們所要強調(diào)的是怎樣減少另一種浪費,即立即驗證剛寫入的數(shù)據(jù)。
在過去的幾年中,我們發(fā)現(xiàn)自己常常會問客戶:“讀并驗證剛寫人的數(shù)據(jù),你認(rèn)為這真的有意義嗎?”這種問題出的率令我們吃驚。有時,客戶的理由很充分,但沒有一條是我們認(rèn)同的。通常,客戶看起來就像是那種被當(dāng)場抓住的知道自己做了不該做的事的孩子。那些對回答經(jīng)過深思熟慮(雖然在我們看來是破壞了價值)的客戶聲稱,他們的應(yīng)用需要絕對確保數(shù)據(jù)不只是被寫入了,還要寫得正確。但要記住,我們絕大多數(shù)客戶都有SaS或商務(wù)平臺,他們不是在運行核電站,也不是要把人類送往太空,更不是在控制幾千架客機的起落或治療癌癥。對于寫錯或者計算錯數(shù)據(jù)的恐懼,一直都是耗費開發(fā)者額外時間的主因。這種恐懼在計算的早期發(fā)展階段可能還算合理,Tanden和Stratus公司分別在20世紀(jì)70年代末期和80年代初期設(shè)計容錯計算機就與這種恐懼有著定的關(guān)系。這種系統(tǒng)的主要意圖是減少系統(tǒng)的平均故障時間(MTTF),采用的方法是“冗余一切”,即包括CPU、存儲、內(nèi)存、內(nèi)存路徑和存儲路徑等在內(nèi)的所有設(shè)備都有冗余。這種模型必須對并行計算和存儲的系統(tǒng)的結(jié)果進行對比,才能驗證系統(tǒng)在正確運行。本書的一位作者曾經(jīng)為一臺年代久遠的Stratus小型計算機開發(fā)過應(yīng)用,在他為此工作的兩年中,該系統(tǒng)從來沒有出現(xiàn)過兩個處理器間的計算錯誤,也沒有出現(xiàn)過寫內(nèi)存或硬盤的錯誤。
現(xiàn)在,這種恐懼已經(jīng)比20世紀(jì)70年代末期和80年代初期少多了。事實上,對那些剛寫入數(shù)據(jù)就要執(zhí)行讀操作的客戶,當(dāng)我們問起他們通常是多長時間會發(fā)現(xiàn)一次錯誤時,他們回答得都相當(dāng)一致,都說從來沒有發(fā)現(xiàn)過。問題是,除非對由于寫操作產(chǎn)生的錯誤數(shù)據(jù)進行操作時發(fā)生了問題,否則他們絕對不會發(fā)現(xiàn)錯誤。當(dāng)然,數(shù)據(jù)損壞也常常發(fā)生,但是大多數(shù)情況下,只有在真正的寫操作時才能發(fā)現(xiàn)這種數(shù)據(jù)損壞。與其投入兩倍的工作量,從而讓存儲、數(shù)據(jù)庫和系統(tǒng)事務(wù)減半,不如看看操作返回的錯誤代碼,進行適當(dāng)?shù)奶幚?。這里補充說明一下,數(shù)據(jù)損壞的好保護措施是正確地做到高可用性,在備用數(shù)據(jù)庫或復(fù)制存儲設(shè)備上保存多個數(shù)據(jù)副本。最理想的情況是最終實現(xiàn)多個實時站點。
當(dāng)然,并非所有的“寫后立即讀”的操作都是由于過分仔細(xì)的程序員為了驗證剛寫入的數(shù)據(jù)而產(chǎn)生的。有時,也可能是最終用戶請求了剛寫人的數(shù)據(jù)。這里,我們不禁要問:為什么這些客戶不把常用的(包括已寫入的)數(shù)據(jù)保存在本地呢?如果剛寫入某些數(shù)據(jù),而且很可能會再用到這些數(shù)據(jù),那么最好把它保存在本地。這種情況一個常見的例子是許多產(chǎn)品中的注冊流程。通常,在把用戶數(shù)據(jù)保存為永久注冊記錄之前,有一個階段會把這些數(shù)據(jù)呈現(xiàn)給用戶。另一個例子,是許多電子商務(wù)站點利用購物車實現(xiàn)的購買流程。無論哪哪種情況,如果你在寫入的數(shù)據(jù)將來還會被用到,那么最好把它們在本地保留一份。關(guān)于如何進行緩存以及緩存哪些數(shù)據(jù)。
前面論述的重點是要得到一個結(jié)論,即重復(fù)操作會降低有效擴展的能力。事實上,它會造成事務(wù)成本加倍。因此,如果你的解決方案要規(guī)避由錯誤的寫操作帶來的幾百萬美金的損失,那可能需要幾千萬的額外基礎(chǔ)設(shè)施作保障。根據(jù)我們的經(jīng)驗,即使在編程時間和基礎(chǔ)設(shè)施上投資了,也沒辦法完全避免這種風(fēng)險。在大多數(shù)情況下,寫后即讀的操作都是不好的,因為它不只讓成本翻倍,限制了擴展性,而且還不能降低風(fēng)險,從而使成本與收益不相稱。毫無疑問,也許會有需要這種操作的地方,但是相比眾多技術(shù)團隊和公司驗證過的好實踐來說,這種情況少之又少。
細(xì)心的讀者可能已經(jīng)發(fā)現(xiàn),我們的原則中存在沖突。需要本地存儲的信息代表狀態(tài),肯定需要跟服務(wù)器保持一致才有用。從宏觀角度說,我們同意這種說法,如果一定要做個選擇,那么我們會只開發(fā)無狀態(tài)的應(yīng)用,以確保不會出現(xiàn)寫后即讀的操作。這說明,我們的原則是常規(guī)的,是“通常如此”的,而不是特定的或“唯一正確”的。絕對不要重復(fù)你的工作,絕對要維護大型的無狀態(tài)應(yīng)用。這兩種說法有沖突嗎?是的。那么沖突可以解決嗎?當(dāng)然要想解決這一原則沖突,就要站在很高的角度來看。我們既想讓系統(tǒng)不浪費資源(如寫后即讀讀),想讓系統(tǒng)是無狀態(tài)的。要實現(xiàn)這一點,我們決定絕對不會為了驗證而讀數(shù)據(jù)。我們也同意,有日時為了速度和擴展,我們也希望保持密切關(guān)系,而不去讀剛寫人的數(shù)據(jù)。這意味著需要維護一些狀態(tài)信息,但是我們可以把它限制在某些事務(wù)中,在這些事務(wù)中讀剛寫入的數(shù)據(jù)是必要的。雖然這種方法有悖于我們介紹的原則,但是如果這種方法在有限的操作中引1人了狀態(tài),從而降低了成本,增加了擴展性,那么它也是可行的。
與所有原則一樣,總有例外的情況。如果你存在于一個受控制的環(huán)境中,要求必須對10096的寫入數(shù)據(jù)進行驗證,然后加密、備份,你應(yīng)該怎么做呢?我們不確定是否存在這樣的環(huán)境,但是如果它存在,就一定要滿足它的要求,例如不能阻止寫后即讀的操作。為了減少寫后即讀的操作且不阻止用戶交易,下面列出了一個問題清單以及你能采用的步驟。
管理要求/法律要求。這個動作是管理要求或者法律要求的嗎?如果是,你確定自己理解得正確嗎?很少會有要求明確說你要做的與用戶交易一致。即使這樣說了,這樣的要求也很少(可能是絕對不)適用于所有操作的。
競爭性差別。這個動作具有競爭性差別嗎?請小心回答,如果答案是“是的”,那么這個答案太一般化了,而且通常是錯誤的。考慮到你所預(yù)計的錯誤發(fā)生的概率很小,你的競爭對手不進行次檢查而造成的錯誤只占所有錯誤的0.001%,那么即使你正確規(guī)避了這些錯誤,也很難令人相信你能戰(zhàn)勝對手。
異步完成。如果出于管理要求(雖然令人懷疑但仍是可能的)或競爭性差別(毫無疑問不可能),必須寫后即讀,那么可以考慮。
在本地寫入,不中斷交易。
網(wǎng)站制作處理故障的方法很多,可以通過日志重建數(shù)據(jù),然后再從處理隊列中重新執(zhí)行,最糟糕的情況是要求用戶再輸入一次數(shù)據(jù),這種情況發(fā)生的概率很小。如果故障發(fā)生在為了實現(xiàn)高可用性而向遠程數(shù)據(jù)備份復(fù)制數(shù)據(jù)的過程中,那么只需要重新申請那個記錄或交易即可。在任何情況下,都不要因為要向兩個數(shù)據(jù)源同步寫入數(shù)據(jù)而中斷用戶交易。
網(wǎng)站欄目:不要立即檢查剛做過的工作
網(wǎng)站網(wǎng)址:http://www.rwnh.cn/news28/151078.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、用戶體驗、網(wǎng)站策劃、軟件開發(fā)、服務(wù)器托管、外貿(mào)建站
廣告
聲明:本網(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)