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