update zh-tw.py to handle the translation issues with 髮 and 發

bin/zh-tw.py

@@ -4,7 +4,13 @@
 def convert(src_path, dst_path, cfg='s2twp.json'):
     converter = opencc.OpenCC(cfg)
     with open(src_path, "r", encoding='utf-8') as src, open(dst_path, "w+", encoding='utf-8') as dst:
-        dst.write("\n".join(converter.convert(line.rstrip()).replace('(img/', '(../img/') for line in src))
+        dst.write("\n".join(
+            converter.convert(line.rstrip()).replace('(img/', '(../img/')
+                .replace('髮送', '傳送')
+                .replace('髮布', '釋出')
+                .replace('髮生', '發生')
+                .replace('髮出', '發出')
+                for line in src))
     print("convert %s to %s" % (src_path, dst_path))
 
 

ch5.md

@@ -265,7 +265,7 @@ PostgreSQL和Oracle等使用这种复制方法【16】。主要缺点是日志
 > *Mr. Poons*
 > ​	Mrs. Cake，你能看到多远的未来？
 
-对于观察者来说，看起来好像Cake夫人在Poons先生发问前就回答了这个问题。
+对于观察者来说，看起来好像Cake夫人在Poons先生提问前就回答了这个问题。
  这种超能力让人印象深刻，但也会把人搞糊涂。【25】。
 
 ![](img/fig5-5.png)

zh-tw/ch1.md

@@ -154,7 +154,7 @@
 
 ***釋出推文***
 
-使用者可以向其粉絲髮布新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。
+使用者可以向其粉絲釋出新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。
 
 ***主頁時間線***
 
@@ -187,7 +187,7 @@
 
 推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作。
 
-然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲髮送推文。
+然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲傳送推文。
 
 在推特的例子中，每個使用者粉絲數的分佈（可能按這些使用者的發推頻率來加權）是探討可伸縮性的一個關鍵負載引數，因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵，但可以採用相似的原則來考慮它的負載。
 
@@ -234,7 +234,7 @@
 
 **排隊延遲（queueing delay）** 通常佔了高百分位點處響應時間的很大一部分。由於伺服器只能並行處理少量的事務（如受其CPU核數的限制），所以只要有少量緩慢的請求就能阻礙後續請求的處理，這種效應有時被稱為 **頭部阻塞（head-of-line blocking）** 。即使後續請求在伺服器上處理的非常迅速，由於需要等待先前請求完成，客戶端最終看到的是緩慢的總體響應時間。因為存在這種效應，測量客戶端的響應時間非常重要。
 
-為測試系統的可伸縮性而人為產生負載時，產生負載的客戶端要獨立於響應時間不斷髮送請求。如果客戶端在傳送下一個請求之前等待先前的請求完成，這種行為會產生人為排隊的效果，使得測試時的佇列比現實情況更短，使測量結果產生偏差【23】。
+為測試系統的可伸縮性而人為產生負載時，產生負載的客戶端要獨立於響應時間不斷傳送請求。如果客戶端在傳送下一個請求之前等待先前的請求完成，這種行為會產生人為排隊的效果，使得測試時的佇列比現實情況更短，使測量結果產生偏差【23】。
 
 > #### 實踐中的百分位點
 >

zh-tw/ch10.md

@@ -618,7 +618,7 @@ Spark，Flink和Tez避免將中間狀態寫入HDFS，因此它們採取了不同
 
 回想一下在MapReduce中，Mapper在概念上向Reducer的特定呼叫“傳送訊息”，因為框架將所有具有相同鍵的Mapper輸出集中在一起。 Pregel背後有一個類似的想法：一個頂點可以向另一個頂點“傳送訊息”，通常這些訊息是沿著圖的邊傳送的。
 
-在每次迭代中，為每個頂點呼叫一個函式，將所有傳送給它的訊息傳遞給它 —— 就像呼叫Reducer一樣。與MapReduce的不同之處在於，在Pregel模型中，頂點在一次迭代到下一次迭代的過程中會記住它的狀態，所以這個函式只需要處理新的傳入訊息。如果圖的某個部分沒有被髮送訊息，那裡就不需要做任何工作。
+在每次迭代中，為每個頂點呼叫一個函式，將所有傳送給它的訊息傳遞給它 —— 就像呼叫Reducer一樣。與MapReduce的不同之處在於，在Pregel模型中，頂點在一次迭代到下一次迭代的過程中會記住它的狀態，所以這個函式只需要處理新的傳入訊息。如果圖的某個部分沒有被傳送訊息，那裡就不需要做任何工作。
 
 這與Actor模型有些相似（請參閱“[分散式的Actor框架](ch4.md#分散式的Actor框架)”），除了頂點狀態和頂點之間的訊息具有容錯性和永續性，且通訊以固定的回合進行：在每次迭代中，框架遞送上次迭代中傳送的所有訊息。Actor通常沒有這樣的時序保證。
 

zh-tw/ch11.md

@@ -643,11 +643,11 @@ GROUP BY follows.follower_id
 
 Apache Flink則使用不同的方法，它會定期生成狀態的滾動存檔點並將其寫入持久儲存【92,93】。如果流運算元崩潰，它可以從最近的存檔點重啟，並丟棄從最近檢查點到崩潰之間的所有輸出。存檔點會由訊息流中的**壁障（barrier）** 觸發，類似於微批次之間的邊界，但不會強制一個特定的視窗大小。
 
-在流處理框架的範圍內，微批次與存檔點方法提供了與批處理一樣的**恰好一次語義**。但是，只要輸出離開流處理器（例如，寫入資料庫，向外部訊息代理髮送訊息，或傳送電子郵件），框架就無法拋棄失敗批次的輸出了。在這種情況下，重啟失敗任務會導致外部副作用發生兩次，只有微批次或存檔點不足以阻止這一問題。
+在流處理框架的範圍內，微批次與存檔點方法提供了與批處理一樣的**恰好一次語義**。但是，只要輸出離開流處理器（例如，寫入資料庫，向外部訊息代理傳送訊息，或傳送電子郵件），框架就無法拋棄失敗批次的輸出了。在這種情況下，重啟失敗任務會導致外部副作用發生兩次，只有微批次或存檔點不足以阻止這一問題。
 
 #### 原子提交再現
 
-為了在出現故障時表現出恰好處理一次的樣子，我們需要確保事件處理的所有輸出和副作用**當且僅當**處理成功時才會生效。這些影響包括髮送給下游運算元或外部訊息傳遞系統（包括電子郵件或推送通知）的任何訊息，任何資料庫寫入，對運算元狀態的任何變更，以及對輸入訊息的任何確認（包括在基於日誌的訊息代理中將消費者偏移量前移）。
+為了在出現故障時表現出恰好處理一次的樣子，我們需要確保事件處理的所有輸出和副作用**當且僅當**處理成功時才會生效。這些影響包括傳送給下游運算元或外部訊息傳遞系統（包括電子郵件或推送通知）的任何訊息，任何資料庫寫入，對運算元狀態的任何變更，以及對輸入訊息的任何確認（包括在基於日誌的訊息代理中將消費者偏移量前移）。
 
 這些事情要麼都原子地發生，要麼都不發生，但是它們不應當失去同步。如果這種方法聽起來很熟悉，那是因為我們在分散式事務和兩階段提交的上下文中討論過它（請參閱“[恰好一次的訊息處理](ch9.md#恰好一次的訊息處理)”）。
 

zh-tw/ch12.md

@@ -554,7 +554,7 @@ COMMIT;
 但事實證明，使用分割槽日誌可以達到等價的正確性而無需原子提交：
 
 1. 從賬戶A向賬戶B轉賬的請求由客戶端提供一個唯一的請求ID，並按請求ID追加寫入相應日誌分割槽。
-2. 流處理器讀取請求日誌。對於每個請求訊息，它向輸出流發出兩條訊息：付款人賬戶A的借記指令（按A分割槽），收款人B的貸記指令（按B分割槽）。被髮出的訊息中會帶有原始的請求ID。
+2. 流處理器讀取請求日誌。對於每個請求訊息，它向輸出流發出兩條訊息：付款人賬戶A的借記指令（按A分割槽），收款人B的貸記指令（按B分割槽）。被發出的訊息中會帶有原始的請求ID。
 3. 後續處理器消費借記/貸記指令流，按照請求ID除重，並將變更應用至賬戶餘額。
 
 步驟1和步驟2是必要的，因為如果客戶直接傳送貸記與借記指令，則需要在這兩個分割槽之間進行原子提交，以確保兩者要麼都發生或都不發生。為了避免對分散式事務的需要，我們首先將請求持久化記錄為單條訊息，然後從這第一條訊息中衍生出貸記指令與借記指令。幾乎在所有資料系統中，單物件寫入都是原子性的（請參閱“[單物件寫入](ch7.md#單物件寫入)），因此請求要麼出現在日誌中，要麼就不出現，無需多分割槽原子提交。

zh-tw/ch5.md

@@ -265,7 +265,7 @@ PostgreSQL和Oracle等使用這種複製方法【16】。主要缺點是日誌
 > *Mr. Poons*
 > ​	Mrs. Cake，你能看到多遠的未來？
 
-對於觀察者來說，看起來好像Cake夫人在Poons先生髮問前就回答了這個問題。
+對於觀察者來說，看起來好像Cake夫人在Poons先生提問前就回答了這個問題。
  這種超能力讓人印象深刻，但也會把人搞糊塗。【25】。
 
 ![](../img/fig5-5.png)
@@ -538,7 +538,7 @@ PostgreSQL和Oracle等使用這種複製方法【16】。主要缺點是日誌
 
 通常，r和w被選為多數（超過 $n/2$ ）節點，因為這確保了$w + r> n$，同時仍然容忍多達$n/2$個節點故障。但是，法定人數不一定必須是大多數，只是讀寫使用的節點交集至少需要包括一個節點。其他法定人數的配置是可能的，這使得分散式演算法的設計有一定的靈活性【45】。
 
-你也可以將w和r設定為較小的數字，以使$w + r≤n$（即法定條件不滿足）。在這種情況下，讀取和寫入操作仍將被髮送到n個節點，但操作成功只需要少量的成功響應。
+你也可以將w和r設定為較小的數字，以使$w + r≤n$（即法定條件不滿足）。在這種情況下，讀取和寫入操作仍將被傳送到n個節點，但操作成功只需要少量的成功響應。
 
 較小的w和r更有可能會讀取過時的資料，因為你的讀取更有可能不包含具有最新值的節點。另一方面，這種配置允許更低的延遲和更高的可用性：如果存在網路中斷，並且許多副本變得無法訪問，則可以繼續處理讀取和寫入的機會更大。只有當可達副本的數量低於w或r時，資料庫才分別變得不可用於寫入或讀取。
 
@@ -578,7 +578,7 @@ PostgreSQL和Oracle等使用這種複製方法【16】。主要缺點是日誌
 
 後者被認為是一個**寬鬆的法定人數（sloppy quorum）**【37】：寫和讀仍然需要w和r成功的響應，但這些響應可能來自不在指定的n個“主”節點中的其它節點。比方說，如果你把自己鎖在房子外面，你可能會敲開鄰居的門，問你是否可以暫時呆在沙發上。
 
-一旦網路中斷得到解決，代表另一個節點臨時接受的一個節點的任何寫入都被髮送到適當的“主”節點。這就是所謂的**提示移交（hinted handoff）**。 （一旦你再次找到你的房子的鑰匙，你的鄰居禮貌地要求你離開沙發回家。）
+一旦網路中斷得到解決，代表另一個節點臨時接受的一個節點的任何寫入都被傳送到適當的“主”節點。這就是所謂的**提示移交（hinted handoff）**。 （一旦你再次找到你的房子的鑰匙，你的鄰居禮貌地要求你離開沙發回家。）
 
 寬鬆的法定人數對寫入可用性的提高特別有用：只要有任何w節點可用，資料庫就可以接受寫入。然而，這意味著即使當$w + r> n$時，也不能確定讀取某個鍵的最新值，因為最新的值可能已經臨時寫入了n之外的某些節點【47】。
 

zh-tw/ch6.md

@@ -268,7 +268,7 @@ Cassandra和Ketama使用的第三種方法是使分割槽數與節點數成正
 
 **圖6-7 將請求路由到正確節點的三種不同方式。**
 
-這是一個具有挑戰性的問題，因為重要的是所有參與者都達成共識 - 否則請求將被髮送到錯誤的節點，得不到正確的處理。 在分散式系統中有達成共識的協議，但很難正確地實現（見[第九章](ch9.md)）。
+這是一個具有挑戰性的問題，因為重要的是所有參與者都達成共識 - 否則請求將被傳送到錯誤的節點，得不到正確的處理。 在分散式系統中有達成共識的協議，但很難正確地實現（見[第九章](ch9.md)）。
 
 許多分散式資料系統都依賴於一個獨立的協調服務，比如ZooKeeper來跟蹤叢集元資料，如[圖6-8](../img/fig6-8.png)所示。 每個節點在ZooKeeper中註冊自己，ZooKeeper維護分割槽到節點的可靠對映。 其他參與者（如路由層或分割槽感知客戶端）可以在ZooKeeper中訂閱此資訊。 只要分割槽分配發生了改變，或者叢集中新增或刪除了一個節點，ZooKeeper就會通知路由層使路由資訊保持最新狀態。
 

zh-tw/ch7.md

@@ -160,7 +160,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
 
 多物件事務需要某種方式來確定哪些讀寫操作屬於同一個事務。在關係型資料庫中，通常基於客戶端與資料庫伺服器的TCP連線：在任何特定連線上，`BEGIN TRANSACTION` 和 `COMMIT` 語句之間的所有內容，被認為是同一事務的一部分.[^iii]
 
-[^iii]: 這並不完美。如果TCP連線中斷，則事務必須中止。如果中斷髮生在客戶端請求提交之後，但在伺服器確認提交發生之前，客戶端並不知道事務是否已提交。為了解決這個問題，事務管理器可以透過一個唯一事務識別符號來對操作進行分組，這個識別符號並未繫結到特定TCP連線。後續再“[資料庫的端到端原則](ch12.md#資料庫的端到端原則)”一節將回到這個主題。
+[^iii]: 這並不完美。如果TCP連線中斷，則事務必須中止。如果中斷發生在客戶端請求提交之後，但在伺服器確認提交發生之前，客戶端並不知道事務是否已提交。為了解決這個問題，事務管理器可以透過一個唯一事務識別符號來對操作進行分組，這個識別符號並未繫結到特定TCP連線。後續再“[資料庫的端到端原則](ch12.md#資料庫的端到端原則)”一節將回到這個主題。
 
 另一方面，許多非關係資料庫並沒有將這些操作組合在一起的方法。即使存在多物件API（例如，某鍵值儲存可能具有在一個操作中更新幾個鍵的multi-put操作），但這並不一定意味著它具有事務語義：該命令可能在一些鍵上成功，在其他的鍵上失敗，使資料庫處於部分更新的狀態。