1、常見指標

Send 1M bytes over 1Gbps network（基於千兆網傳輸1M資料）：10ms

Round trip within data center（同資料中心請求讀取）：0.5ms

Disk seek（磁碟尋道時間）：8~10ms

Read 1MB sequentially from disk（從磁碟順序讀取1M資料）：20~25ms

Read 1M sequentially from memory（從記憶體順序讀取1M資料，速率為：40~50M）： 0.25ms

2、效能估算

需要假設程式的執行環境，如叢集規模及機器配置，叢集上其它服務佔用資源的比例。

常見估算場景:

1）、記憶體排序時間估算：排序時間 = 比較時間（分支預測錯誤） + 記憶體訪問時間。

2）、MapReduce應用處理時間：Map處理時間 + shuffle和排序時間 + reduce處理時間（雖然shuffle、map處理和排序可以部分並行，但效能估算的時候不必考慮）；Map處理時間 = 輸入讀取時間 + Map函式處理時間 + 輸出中間結果時間；Reduce處理時間 = reduce函式處理時間 + 最終結果輸出時間

3）、Bigtable設計的效能指標分析：單個磁碟讀取時間：磁碟尋道時間 + 讀取時間；可達到的理論值：n個盤*1/單個磁碟讀取時間

3、CAP

一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結果；

可用性(Availability)：每一個操作總是能夠在確定的時間內返回；

分割槽可容忍性(Tolerance of network Partition)：在出現網路分割槽的情況下，仍然能夠滿足一致性和可用性；

CAP理論認為，三者不能同時滿足，證明如下：假設系統出現網路分割槽為G1和G2兩個部分，在一個寫操作W1後面有一個讀操作R2，W1寫G1，R2讀取G2，由於G1和 G2不能通訊，如果讀操作R2可以終結的話，必定不能讀取寫操作W1的操作結果。

4、一致性模型

1）強一致性

2）弱一致性：存在“不一致性視窗”，不能保證後續讀取操作能讀取到最新值。

3）最終一致性：，如果沒有失敗發生的話，“不一致性視窗”的大小依賴於以下的幾個因素：互動延遲，系統的負載，以及複製技術中replica的個數。

5、NOSQL與SQL

常見模型：

KV模型：只支援最簡單的針對<key, value>對的操作；

支援簡單table schema的模型，如Bigtable模型

NOSQL有一些共同的設計原則：

假設失效是必然發生的

限定應用模式，支援的介面永遠不可能和SQL相比

擴容支援成倍增加，常用演算法：一致性Hash

6、Two-Phase commit

說明參考：http://www.nosqlnotes.net/archives/62#more-62

Two-phase commit的演算法實現 (from <<Distributed System: Principles and Paradigms>>)：
協調者(Coordinator)：
write START_2PC to local log;
multicast VOTE_REQUEST to all participants;
while not all votes have been collected {
wait for any incoming vote;
if timeout {
write GLOBAL_ABORT to local log;
multicast GLOBAL_ABORT to all participants;
exit;
}
record vote;
}
if all participants sent VOTE_COMMIT and coordinator votes COMMIT {
write GLOBAL_COMMIT to local log;
multicast GLOBAL_COMMIT to all participants;

} else {
write GLOBAL_ABORT to local log;
multicast GLOBAL_ABORT to all participants;
}
參與者(Participants)
write INIT to local log;
wait for VOTE_REQUEST from coordinator;
if timeout {
write VOTE_ABORT to local log;
exit;
}
if participant votes COMMIT {
write VOTE_COMMIT to local log;
send VOTE_COMMIT to coordinator;
wait for DECISION from coordinator;
if timeout {
multicast DECISION_REQUEST to other participants;
wait until DECISION is received; /* remain blocked*/
write DECISION to local log;
}
if DECISION == GLOBAL_COMMIT
write GLOBAL_COMMIT to local log;
else ifDECISION == GLOBAL_ABORT
write GLOBAL_ABORT to local log;
} else {
write VOTE_ABORT to local log;
send VOTE_ABORT to coordinator;
}

另外，每個參與者維護一個執行緒專門處理其它參與者的DECISION_REQUEST請求，處理執行緒流程如下：
while true {
wait until any incoming DECISION_REQUEST is received;
read most recently recorded STATE from the local log;
if STATE == GLOBAL_COMMIT
send GLOBAL_COMMIT to requesting participant;
else if STATE == INIT or STATE == GLOBAL_ABORT;
send GLOBAL_ABORT to requesting participant;
else
skip; /* participant remains blocked */
}

如果協調者出現類似磁碟壞這種永久性錯誤，該事務將成為被永久遺棄的孤兒。一種可行的解決方法是當前的協調者宕機的時候有其它的備用協調者接替，用於同一時刻只能允許一個協調者存在，二者之間有一個選舉的過程，這裡需要用到Paxos協議。

7、Paxos

Paxos選舉過程如下：
 Phase 1
(a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors.
(b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.
 Phase 2
(a) If the proposer receives a response to its prepare requests (numbered n) from a majority of acceptors, then it sends an accept request to each of those acceptors for a proposal numbered n

with a value v, where v is the value of the highest-numbered proposal among the responses, or is any value if the responses reported no proposals.
(b) If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare request having a number greater than n.