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