始读于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很快就会发现，并重新提议其中序号最大的提议值。
因此，随着协议不断运行，它会往“某个提议值被多数派接受并生效”这一最终目标
靠拢。
附件列表