始讀於2014年5月31日兔家中，前三章完成於2014年6月10日22:21:41
后幾張是講一些具體產品的內容，對於每一個產品，都需要確實的使用和經驗，以后需要的時候再研究不遲，技術永遠在使用中進步更大。
以前對存儲尤其是分布式存儲的整體知識體系不是太清楚，只是片段式的知道一些理論，通過此書的學習，對分布式存儲的原理將豁然開朗，不管是理論的還是后面幾章講述的具體產品，都能做到知其然知其所以然。另外，書中對Paxos協議也進行了深入介紹，理解此協議對時下流行的去中心化將有“夫子言之,於我心有戚戚焉”的感覺。
當然，如果想完全徹底了解更底層一些的存儲知識，建議閱讀冬瓜頭的《大話存儲2》（此書過后，存儲從此無戰事矣）。
全書思維導圖：
Paxos協議過程：
1.
單機存儲引擎就是哈希表、B樹等數據結構在機械磁盤、SSD等持久化介質上的實
現。單機存儲系統是單機存儲引擎的一種封裝，對外提供文件、鍵值、表格或者關系模
型
2.IO南北橋架構：北橋芯片通過前端總線（Front Side Bus，FSB）與CPU相連，內存模塊以及PCI-E設備（如高端的SSD設備Fusion-IO）掛接在北橋上。北橋與南橋之間通過DMI連接，DMI的帶寬為1GB/s，網卡（包括千兆以及萬兆網卡），硬盤以及中低端固態盤（如Intel 320系列 SSD）掛接在南橋上
3.常用硬件性能參數：
4.SMP(Symmetric Multi-Processing)結構
5.存儲引擎是存儲系統的發動機，直接決定了存儲系統能夠提供的性能和功能.
6.
哈希存儲引擎是哈希表的持久化實現，支持增、刪、改，以及隨機讀取操作，但不支持
順序掃描，對應的存儲系統為鍵值（Key-Value）存儲系統
7.B樹（B-Tree）存儲引擎是
B樹的持久化實現，不僅支持單條記錄的增、刪、讀、改操作，還支持順序掃描，對
應的存儲系統是關系數據庫。當然鍵值系統也可以通過B樹存儲引擎實現
8.LSM樹
（Log-Structured Merge Tree）存儲引擎和B樹存儲引擎一樣，支持增、刪、改、隨機讀
取以及順序掃描。它通過批量轉儲技術規避磁盤隨機寫入問題，廣泛應用於互聯網的后
台存儲系統。
9.
LSM樹（Log Structured Merge Tree）的思想非常朴素
就是將對數據的修改增量
保持在內存中，達到指定的大小限制后將這些修改操作批量寫入磁盤，讀取時需要合並
磁盤中的歷史數據和內存中最近的修改操作。LSM樹的優勢在於有效地規避了磁盤隨
機寫入問題，但讀取時可能需要訪問較多的磁盤文件
10.
POSIX（Portable Operating System Interface）是應用程序訪問文件系統的API標准，
它定義了文件系統存儲接口及操作集。
POSIX標准適合單機
文件系統，在分布式文件系統中，出於性能考慮，一般不會完全遵守這個標准。
11.NFS
（Network File System）文件系統允許客戶端緩存文件數據，多個客戶端並發修改同一
個文件時可能出現不一致的情況。
12.
關系數據庫采用B樹存儲引擎，更新操作性能不如LSM樹這樣的存儲引
擎。另外，如果只有基於主鍵的增、刪、查、改操作，關系數據庫的性能也不如
專門定制的Key-Value存儲系統。
13.
壓縮的本質就是找數據的重復或者規律，用盡量少的字節表示。
Huffman編碼是一種基於編碼的優化技術，通過統計字符出現的頻率來計算最優前
綴編碼。LZ系列算法一般有一個窗口的概念，在窗口內部找重復並維護數據字典。常
用的壓縮算法包括Gzip、LZW、LZO
14.
分布式系統中有兩個重要的協議，包括Paxos選舉協議以及兩階段提交協議。
Paxos協議用於多個節點之間達成一致，往往用於實現總控節點選舉。兩階段提交協議
用於保證跨多個節點操作的原子性，這些操作要么全部成功，要么全部失敗。
15.分布-->復制
-->一致性
-->容錯。
副本是分布式存儲系統容錯技術的唯一手段。由於多個副本的存
在，如何保證副本之間的一致性是整個分布式系統的理論核心。
16.常見分布式故障：
17.分布式系統中的單層結構和雙層結構：
18.
主流的分布式存儲系統大多帶有
總控節點，且能夠支持成千上萬台的集群規模。
19.盡量減少對總控節點的壓力，一般分布式文件系統相比其他分布式系統需要存一些目錄信息，可能支持上萬集群機器的時候存在瓶頸，可以通過兩層結構的方式，總控節點存root信息，第二層節點存meta信息
20.
將存儲節點分為若干組，每個組內的節點服務完全相同的數據，其中有一個節點為
主節點，其他節點為備節點。由於同一個組內的節點服務相同的數據，這樣的系統稱為
同構系統。
同構系統擴容時需要從單個節點拷貝大量數據，不適合自動化
21.
異構系統將數據划分為很多大小接近的分片，每個分片的多個副本可以分布
到集群中的任何一個存儲節點。如果某個節點發生故障，原有的服務將由整個集群而不
是某幾個固定的存儲節點來恢復
22.分布式重要的兩個協議：
兩階段提交協議用於保證跨多個節點操作的原子
性，也就是說，跨多個節點的操作要么在所有節點上全部執行成功，要么全部失敗。
Paxos協議用於確保多個節點對某個投票（例如哪個節點為主節點）達成一致。
Paxos協議有兩種用法：一種用法是用它來實現全局的鎖服務或者命名和配置服務，
例如Google Chubby以及Apache Zookeeper。另外一種用法是用它來將用戶數據復制到
多個數據中心，例如Google Megastore以及Google Spanner
23.
為了實現高可用性，主節點往往將數據以操作日志的形式同步到備節點。如果主節
點發生故障，備節點會提議自己成為主節點
24.
Paxos協議執行步驟如下：
1）批准（accept）：Proposer發送accept消息要求所有其他節點（acceptor，接受
者）接受某個提議值，acceptor可以接受或者拒絕。
2）確認（acknowledge）：
如果超過一半的acceptor接受，意味着提議值已經生效，
proposer發送acknowledge消息通知所有的acceptor提議生效。
當出現網絡或者其他異常時，系統中可能存在多個proposer，他們各自發起不同的
提議。這里的提議可以是一個修改操作，也可以是提議自己成為主節點。如果proposer
第一次發起的accept請求沒有被acceptor中的多數派批准（例如與其他proposer的提
議沖突），那么，需要完整地執行一輪Paxos協議。過程如下：
1）准備（prepare）：Proposer首先選擇一個提議序號n給其他的acceptor節點發
送prepare消息。Acceptor收到prepare消息后，如果提議的序號大於他已經回復的所有
prepare消息，則acceptor將自己上次接受的提議回復給proposer，並承諾不再回復小於
n的提議。
2）批准（accept）：Proposer收到了acceptor中的多數派對prepare的回復后，就
進入批准階段。如果在之前的prepare階段acceptor回復了上次接受的提議，那么，
proposer選擇其中序號最大的提議值發給acceptor批准；否則，proposer生成一個新的
提議值發給acceptor批准。Acceptor在不違背他之前在prepare階段的承諾的前提下，
接受這個請求。
3）確認（acknowledge）：如果超過一半的acceptor接受，提議值生效。Proposer
發送acknowledge消息通知所有的acceptor提議生效。
Paxos協議需要考慮兩個問題：正確性，即只有一個提議值會生效；可終止性，即
最后總會有一個提議值生效。Paxos協議中要求每個生效的提議被acceptor中的多數派
接受，並且每個acceptor不會接受兩個不同的提議，因此可以保證正確性。Paxos協議
並不能夠嚴格保證可終止性。但是，從Paxos協議的執行過程可以看出，只要超過一
個acceptor接受了提議，proposer很快就會發現，並重新提議其中序號最大的提議值。
因此，隨着協議不斷運行，它會往“某個提議值被多數派接受並生效”這一最終目標
靠攏。
附件列表