（二）分布式存储原理与设计

主要介绍分布式存储的原理与设计，包括以下内容：

1. 单机存储原理与设计
2. 多机存储原理与设计
3. FLP定理与设计
4. CAP定理与设计
5. 2PC协议与设计
6. Paxos协议与设计

---

单机存储原理与设计

1. 单机存储引擎：存储引擎是存储系统的发动机，决定了存储系统能够提供的功能和性能。存储系统提供功能：Create、Update、Read、Delete（CURD）。存储引擎类型有：
   · 哈希存储引擎
   · B树存储引擎
   · LSM存储引擎
2. 哈希存储引擎：基于哈希表结构的键值存储系统，数组+链表的方式实现，支持持Create、Update、Delete、随机Read，O(1)Read复杂度。
3. B树存储引擎：基于B Tree实现，支持单条记录的CURD，还支持顺序扫描、范围查找，RDBMS使用较多，例如：MySQL，InnoDB 聚簇索引，B+树。
4. LSM树存储引擎：Log Structured Merge Tree，对数据的修改增量保存在内存中，达到指定条件后（通常是数量和时间间隔），批量将更新操作持久到磁盘，读取数据时需要合并磁盘中的历史数据和内存中最近修改操作，LSM优势在于通过批量写入，规避了随机写入问题，提高写入性能，LSM劣势在于读取需要合并磁盘数据和内存数据。LSM通过Commit Log避免了内存数据丢失，首先将修改操作作写入到Commit Log中，保证操作数据的可靠性。 典型案例设计：LevelDB。
5. 数据模型：数据模型是存储系统外壳，分类有：
   · 文件：以目录树的方式组织文件 Linux、Mac、Windows
   · 关系型：每个关系是一个表格，由多个行组成，每个行由于多个列组成，如MySQL、Orcale等
   · 键值(Key-Value)存储型：Memcached、 Tokyo Cabinet、Redis
   · 列存储型：Cassadra、HBase
   · 图形(Graph)数据库：Neo4J、InfoGrid、Infinite Graph
   · 文档型：MongoDB、CouchDB
6. 事务与并发控制
   · 事物四个基本属性：原子性、一致性、隔离性、持久性
   · 并发控制：锁粒度，MongoDB：Process->DB->Table->Row，提供Read并发，Read不加锁：写时复制、MVCC
7. 数据恢复：操作日志

---

多机存储原理与设计

1. 单机存储与多机存储：单机存储的原理在多机存储仍然可用，多级存储基于单机存储。
2. 多机数据分布：区别于单机存储，数据分布在多个节点上，在多个节点之间需要实现负载均衡，数据分布方式：
   · 静态方式：取模，uid%32。
   · 动态方式：一致性hash，会有数据漂移的问题。
   负载均衡：多节点之间数据的均衡，负载高的节点迁移到负载低的节点（数据迁移）。
3. 复制：分布式存储多个副本，保证了高可靠和高可用，Commit Log。
4. 故障检测：心跳机制、数据迁移、故障恢复。

---

FLP定理与设计

1. FLP：FLP Impossibility（FLP不可能性）是分布式领域中一个非常著名的结果，1985年Fischer、Lynch and Patterson三位作者发表论文，并获取Dijkstra奖，在异步消息通信场景，即使只有一个进程失败，没有任何方法能够保证非失败进程达到一致性。
2. FLP系统模型基于以下几个假设：
   
   1. 异步通信：与同步通信最大区别是没有时钟、不能时间同步、不能使用超时、不能探测失败、消息可任意延迟、消息可乱序
   2. 通信健壮性：只要进程非失败，消息虽会被无限延迟，但最终会被送达，并且消息仅会被送达一次（重复保证）
   3. Fail-Stop模型：进程失败不再处理任何消息
   4. 失败进程数量：最多一个进程失败
3. FLP定理带给我们的启示：
   1985年FLP证明了异步通信中不存在任何一致性的分布式算法（FLP Impossibility），人们就开始寻找分布式系统设计的各种因素，一致性算法既然不存在，如果能找到一些设计因素，适当取舍以最大限度满足实现系统需求成为当时的重要议题，出现了CAP定理。

---

CAP定理与设计

1. CAP定理：2000年Berkerly的Eric Brewer教授提出了一个著名的CAP理论，CAP是一致性(Consistency)、可用性(Availability)、分区可容忍性(Tolerance of network Partition)的首字母缩写。在分布式环境下，三者不可能同时满足。
   
   1. 一致性(Consistency)：Read的数据总是最新的（Write的结果），这里指的是强一致性。
   2. 可用性(Availabilty)：机器或者系统部分发生故障，仍然能够正常提供读写服务。
   3. 分区容忍性(Tolerance of network Partition)：机器故障、网络故障、机房故障等异常情况下仍然能够满足一致性和可用性。
      2. CAP设计：分布式存储系统需要能够自动容错，也就是说分区容忍性需要保证。如果保证一致性，需要强同步复制，主副本之间网络异常，写操作被阻塞，可用性无法保证。如果保证可用性，采取异步复制机制，保证了分布式存储系统的可用性，强一致性无法保证，设计时一致性和可用性需要折中权衡。金融行业中，不允许数据丢失，需要强一致性。

---

2PC协议与设计

1. 2PC协议：Two Phase Commit（2PC），用于实现分布式事物，有两类节点，协调者和事物参与者，每个节点都会记录Commit Log，保证数据可靠性，两阶段提交由两个阶段组成：
   
   1. 请求阶段（Prepare Phase）：协调者通知参与者准备提交或者取消事务，之后进入表决阶段，每个参与者将告知协调者自己的决策：同意or不同意
   2. 提交阶段（Commit Phase）：收到参与者的所有决策后，进行决策：提交or取消，通知参与者执行操作：所有参与者都同意，提交 or 取消，参与者收到协调者的通知后执行操作
2. 2PC协议与设计：2PC协议是阻塞式，事务参与者可能发生故障：设置超时时间，协调者可能发生故障：日志记录，备用协调者。

---

Paxos协议与设计

1. Paxos协议：用于解决多个节点之间的一致性问题，多个节点，只有一个主节点，主节点挂掉，如果选举新的节点，主节点往往以操作日志的形式同步备节点。角色：提议者（Proposer）和接受者（Acceptor）。Proposer发送accept消息到Acceptor要求接受某个提议者，如果超过一半的Acceptor接受，意味着提议值生效，Proposer发送acknowledge消息通知所有的Acceptor提议生效。
2. 2PC与Paxos：作用不同：2PC协议保证多个数据分片上操作的原子性，Paxos协议保证一个数据分片多个副本之间的数据一致性。2PC最大缺陷无法处理协调者宕机，Paxos可以处理协调者宕机，两者可以结合使用。
3. Paxos协议用法：实现全局的锁服务或者命名和配置服务，将用户数据复制到多个数据中心。