大规模分布式存储系统原理解析与架构实战
始读于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很快就会发现，并重新提议其中序号最大的提议值。因此，随着协议不断运行，它会往“某个提议值被多数派接受并生效”这一最终目标靠拢。
附件列表
