不要立即檢查剛做過的事情，也不要立即讀剛寫過的數(shù)據(jù)。絕對不要為了驗證而立即讀剛寫過的數(shù)據(jù)。為了近期內(nèi)的運維需要，可以把數(shù)據(jù)存儲在本地或分布式的緩存中。驗證工作相對于不太可能出現(xiàn)的故障來說成本更高。這種活動有悖于有效擴展的需求。

絕對不要為了驗證數(shù)據(jù)而立即讀剛寫入的數(shù)據(jù)，而要讀并處理與寫操作相關(guān)的錯誤。把數(shù)據(jù)存儲在本地可以避免對剛剛寫入的數(shù)據(jù)的其他讀操作。

木匠有句名言:“量兩次，鋸一次。”你可能從中學的木工老師那里聽過這句話一他可能還缺了根手指。拋開少手指這事不說，這句名言還是很有道理的，正所謂實踐出真知。最好在切割前驗證測量的準確度，因為錯誤的測量結(jié)果會導致生產(chǎn)浪費，例如切出一塊大小不對的木板。我們當然不會那么做。然而，我們所要強調(diào)的是怎樣減少另一種浪費，即立即驗證剛寫入的數(shù)據(jù)。



在過去的幾年中，我們發(fā)現(xiàn)自己常常會問客戶:“讀并驗證剛寫人的數(shù)據(jù)，你認為這真的有意義嗎?”這種問題出的率令我們吃驚。有時，客戶的理由很充分，但沒有一條是我們認同的。通常，客戶看起來就像是那種被當場抓住的知道自己做了不該做的事的孩子。那些對回答經(jīng)過深思熟慮(雖然在我們看來是破壞了價值)的客戶聲稱，他們的應(yīng)用需要絕對確保數(shù)據(jù)不只是被寫入了，還要寫得正確。但要記住，我們絕大多數(shù)客戶都有SaS或商務(wù)平臺，他們不是在運行核電站，也不是要把人類送往太空，更不是在控制幾千架客機的起落或治療癌癥。對于寫錯或者計算錯數(shù)據(jù)的恐懼，一直都是耗費開發(fā)者額外時間的主因。這種恐懼在計算的早期發(fā)展階段可能還算合理，Tanden和 Stratus公司分別在20世紀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世紀70年代末期和80年代初期少多了。事實上，對那些剛寫入數(shù)據(jù)就要執(zhí)行讀操作的客戶，當我們問起他們通常是多長時間會發(fā)現(xiàn)一次錯誤時，他們回答得都相當一致，都說從來沒有發(fā)現(xiàn)過。問題是，除非對由于寫操作產(chǎn)生的錯誤數(shù)據(jù)進行操作時發(fā)生了問題，否則他們絕對不會發(fā)現(xiàn)錯誤。當然，數(shù)據(jù)損壞也常常發(fā)生，但是大多數(shù)情況下，只有在真正的寫操作時才能發(fā)現(xiàn)這種數(shù)據(jù)損壞。與其投入兩倍的工作量，從而讓存儲、數(shù)據(jù)庫和系統(tǒng)事務(wù)減半，不如看看操作返回的錯誤代碼，進行適當?shù)奶幚?。這里補充說明一下，數(shù)據(jù)損壞的最佳保護措施是正確地做到高可用性，在備用數(shù)據(jù)庫或復制存儲設(shè)備上保存多個數(shù)據(jù)副本。最理想的情況是最終實現(xiàn)多個實時站點。

當然，并非所有的“寫后立即讀”的操作都是由于過分仔細的程序員為了驗證剛寫入的數(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é)論，即重復操作會降低有效擴展的能力。事實上，它會造成事務(wù)成本加倍。因此，如果你的解決方案要規(guī)避由錯誤的寫操作帶來的幾百萬美金的損失，那可能需要幾千萬的額外基礎(chǔ)設(shè)施作保障。根據(jù)我們的經(jīng)驗，即使在編程時間和基礎(chǔ)設(shè)施上投資了，也沒辦法完全避免這種風險。在大多數(shù)情況下，寫后即讀的操作都是不好的，因為它不只讓成本翻倍，限制了擴展性，而且還不能降低風險，從而使成本與收益不相稱。毫無疑問，也許會有需要這種操作的地方，但是相比眾多技術(shù)團隊和公司驗證過的最佳實踐來說，這種情況少之又少。

細心的讀者可能已經(jīng)發(fā)現(xiàn)，我們的原則中存在沖突。需要本地存儲的信息代表狀態(tài)，肯定需要跟服務(wù)器保持一致才有用。從宏觀角度說，我們同意這種說法，如果一定要做個選擇，那么我們會只開發(fā)無狀態(tài)的應(yīng)用，以確保不會出現(xiàn)寫后即讀的操作。這說明，我們的原則是常規(guī)的，是“通常如此”的，而不是特定的或“唯一正確”的。絕對不要重復你的工作，絕對要維護大型的無狀態(tài)應(yī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)境，但是如果它存在，就一定要滿足它的要求，例如不能阻止寫后即讀的操作。為了減少寫后即讀的操作且不阻止用戶交易，下面列出了一個問題清單以及你能采用的步驟。
 
管理要求/法律要求。這個動作是管理要求或者法律要求的嗎?如果是，你確定自己理解得正確嗎?很少會有要求明確說你要做的與用戶交易一致。即使這樣說了，這樣的要求也很少(可能是絕對不)適用于所有操作的。

競爭性差別。這個動作具有競爭性差別嗎?請小心回答，如果答案是“是的”，那么這個答案太一般化了，而且通常是錯誤的?？紤]到你所預計的錯誤發(fā)生的概率很小，你的競爭對手不進行次檢查而造成的錯誤只占所有錯誤的0.001%，那么即使你正確規(guī)避了這些錯誤，也很難令人相信你能戰(zhàn)勝對手。

異步完成。如果出于管理要求(雖然令人懷疑但仍是可能的)或競爭性差別(毫無疑問不可能)，必須寫后即讀，那么可以考慮。

在本地寫入，不中斷交易。網(wǎng)站制作處理故障的方法很多，可以通過日志重建數(shù)據(jù)，然后再從處理隊列中重新執(zhí)行，最糟糕的情況是要求用戶再輸入一次數(shù)據(jù)，這種情況發(fā)生的概率很小。如果故障發(fā)生在為了實現(xiàn)高可用性而向遠程數(shù)據(jù)備份復制數(shù)據(jù)的過程中，那么只需要重新申請那個記錄或交易即可。在任何情況下，都不要因為要向兩個數(shù)據(jù)源同步寫入數(shù)據(jù)而中斷用戶交易。