fix a typo, update zh-tw content

This commit is contained in:
Gang Yin 2023-06-27 19:05:53 +08:00
parent dd67063ab3
commit 5cd1cde9ca
3 changed files with 5 additions and 5 deletions

View File

@ -592,7 +592,7 @@ COMMIT;
我断言在大多数应用中,完整性比及时性重要得多。违反及时性可能令人困惑与讨厌,但违反完整性的结果可能是灾难性的。
例如在你的信用卡对账单上,如果某一笔过去 24 小时内完成的交易尚未出现并不令人奇怪 —— 这些系统有一定的滞后是正常的。我们知道银行是异步核算与敲定交易的这里的及时性并不是非常重要【3】。但果当期对账单余额与上期对账单余额加交易总额对不上求和错误或者出现一笔向你收费但未向商家付款的交易消失的钱实在是太糟糕了。这样的问题就违背了系统的完整性。
例如在你的信用卡对账单上,如果某一笔过去 24 小时内完成的交易尚未出现并不令人奇怪 —— 这些系统有一定的滞后是正常的。我们知道银行是异步核算与敲定交易的这里的及时性并不是非常重要【3】。但果当期对账单余额与上期对账单余额加交易总额对不上(求和错误),或者出现一笔向你收费但未向商家付款的交易(消失的钱),那就实在是太糟糕了,这样的问题就违背了系统的完整性。
#### 数据流系统的正确性

View File

@ -377,7 +377,7 @@ Unix 和關係資料庫以非常不同的哲學來處理資訊管理問題。Uni
一些應用(如即時訊息傳遞與線上遊戲)已經具有這種 “實時” 架構(在低延遲互動的意義上,不是在 “[響應時間保證](ch8.md#響應時間保證)” 中的意義上)。但我們為什麼不用這種方式構建所有的應用?
挑戰在於,關於無狀態客戶端和請求 / 響應互動的假設已經根深蒂固地植入在我們的資料庫、庫、框架以及協議之中。許多資料儲存支援讀取與寫入操作,為請求返回一個響應,但只有極少數提供訂閱變更的能力 —— 請求返回一個隨時間推移的響應流(請參閱 “[變更流的 API 支援](ch11.md#變更流的API支援)” )。
挑戰在於,關於無狀態客戶端和請求 / 響應互動的假設已經根深蒂固地植入在我們的資料庫、庫、框架以及協議之中。許多資料儲存支援讀取與寫入操作,為請求返回一個響應,但只有極少數提供訂閱變更的能力 —— 請求返回一個隨時間推移的響應流(請參閱 “[變更流的 API 支援](ch11.md#變更流的API支援)” )。
為了將寫路徑延伸至終端使用者,我們需要從根本上重新思考我們構建這些系統的方式:從請求 / 響應互動轉向釋出 / 訂閱資料流【27】。更具響應性的使用者介面與更好的離線支援我認為這些優勢值得我們付出努力。如果你正在設計資料系統我希望你對訂閱變更的選項留有印象而不只是查詢當前狀態。
@ -438,7 +438,7 @@ MPP 資料庫的內部查詢執行圖有著類似的特徵(請參閱 “[Hadoo
處理兩次是資料損壞的一種形式:為同樣的服務向客戶收費兩次(收費太多)或增長計數器兩次(誇大指標)都不是我們想要的。在這種情況下,恰好一次意味著安排計算,使得最終效果與沒有發生錯誤的情況一樣,即使操作實際上因為某種錯誤而重試。我們先前討論過實現這一目標的幾種方法。
最有效的方法之一是使操作 **冪等**idempotent請參閱 “[冪等性](ch11.md#冪等性)”)即確保它無論是執行一次還是執行多次都具有相同的效果。但是,將不是天生冪等的操作變為冪等的操作需要一些額外的努力與關注:你可能需要維護一些額外的元資料(例如更新了值的操作 ID 集合),並在從一個節點故障切換至另一個節點時做好防護(請參閱 “[領導者和鎖](ch8.md#領導者和鎖)”)。
最有效的方法之一是使操作 **冪等**idempotent請參閱 “[冪等性](ch11.md#冪等性)”)即確保它無論是執行一次還是執行多次都具有相同的效果。但是,將不是天生冪等的操作變為冪等的操作需要一些額外的努力與關注:你可能需要維護一些額外的元資料(例如更新了值的操作 ID 集合),並在從一個節點故障切換至另一個節點時做好防護(請參閱 “[領導者和鎖](ch8.md#領導者和鎖)”)。
#### 抑制重複
@ -592,7 +592,7 @@ COMMIT;
我斷言在大多數應用中,完整性比及時性重要得多。違反及時性可能令人困惑與討厭,但違反完整性的結果可能是災難性的。
例如在你的信用卡對賬單上,如果某一筆過去 24 小時內完成的交易尚未出現並不令人奇怪 —— 這些系統有一定的滯後是正常的。我們知道銀行是非同步核算與敲定交易的這裡的及時性並不是非常重要【3】。但果當期對賬單餘額與上期對賬單餘額加交易總額對不上求和錯誤或者出現一筆向你收費但未向商家付款的交易消失的錢實在是太糟糕了。這樣的問題就違背了系統的完整性。
例如在你的信用卡對賬單上,如果某一筆過去 24 小時內完成的交易尚未出現並不令人奇怪 —— 這些系統有一定的滯後是正常的。我們知道銀行是非同步核算與敲定交易的這裡的及時性並不是非常重要【3】。但果當期對賬單餘額與上期對賬單餘額加交易總額對不上(求和錯誤),或者出現一筆向你收費但未向商家付款的交易(消失的錢),那就實在是太糟糕了,這樣的問題就違背了系統的完整性。
#### 資料流系統的正確性