大规模高性能分布式存储系统（2月27日）

----分布式事务：分布式事务是指会涉及到操作多个数据的事务，同样需要保证ACID；可以理解为将对同一库事务的概念扩大到了对多个库的事务

实现手段：2PC、3PC

2PC协议与设计：

Two Phase Commit（2PC）实现分布式事务，两类节点：协调者（1个）；事务参与者（多个）；每个节点都会记录Commit Log；保证数据可靠性；两阶段提交由两个阶段组成：请求阶段；提交阶段

请求阶段（Prepare Phase）：协调者通知参与者准备提交或者取消事务，之后进入表决阶段，每个参与者将告知协调者自己的决策，同意或不同意

提交阶段（Commit Phase）：收到参与者的所有决策后，进行决策，提交或取消；通知参与者执行操作，所有参与者都同意，提交，否则取消；参与者收到协调者的通知后执行操作

2PC协议是阻塞式的，事务参与者可能发生故障，设置超时时间；协调者可能发生故障，日志记录，备用协调者；

应用：分布式事务；二手交易（商品库、订单库）

3PC：2PC的改进版，2PC有一些很明显的缺陷，比如在协调者做出commit决策并开始发送commit之后，某个参与者突然崩溃，这时候没法取消事务；这时候集群内实际上就存在不一致的情况，crash恢复后的节点跟其他节点数据是不同的；因此3PC将2PC的commit的过程1分为2；分成precommit及commit。

异步化消息队列：分布式事务问题；效率问题

现实场景：快餐付款后，并没有给你快餐，只给了点餐单；当快餐准备后，异步去取餐；整个过程分为2个过程：付款和取餐；提高并发；提高吞吐量；分布式系统基于消息队列：异步化，最终一致性

----异步化：借助消息队列等

支付转账操作：先从银行扣款，确保扣款成功后（通过事务来确保）；向消息中心发送转账操作，记录下来（重试机制、日志保证）；消息队列异步向下游发送转账操作（Ack机制）

消息重复问题：下游幂等设计；业务状态判断：微信支付

分布式存储系统一致性保证案例

----线上案例情况

转转下单系统（线上二手市场）：只有一个库存；多用户同时下单；分布式锁；基于Redis，

–--SETNX SETNX key value

----EXPIRE EXPIRE key TTL 设置超时

非原子性、业务做处理

第五讲 大规模高性能分布式存储系统之高可用高可靠篇

什么是分布式存储系统高可靠：重点指数据安全方面的指标；数据可靠不丢失；单机（磁盘RAID、日志记录）；多机（日志记录、冗余）

分布式存储系统高可靠的重要性

公司、企业数据是最宝贵的财产，包括用户数据、商品数据、订单数据、交易数据、IM数据等；

一旦丢失，对公司的打击是致命的

数据高可靠是企业的命根，一定要保证

什么是分布式存储系统高可用：指系统在面对各种异常时可以提供正常服务的能力；系统的可用性可以用系统停服的时间和正常服务时间的比例来衡量；系统不可用时间（故障时间=故障修复时间点-故障发现时间点）；4个9的可用性（99.99%），一年停机时间不能超过53分钟

2个9的可用性（99%），基本可用，一年停机的时间不能超过88个小时，365×24×60/100=88小时

3个9的可用性（99.9%），较高可用性，一年停机的时间不能超过9个小时，3652460/1000=9小时

4个9的可用性（99.99%），具备自动恢复能力的高可用，一年停机的时间不能超过53分钟，3652460/10000=53分钟

5个9的可用性（99.999%），极高可用性，一年停机的时间不能超过5分钟，3652460/100000=5分钟

存储系统可用性：较多的大网站可用性不足2个9,88小时，Twitter网站，国内的网站

目标：做到4个9或者更高，具备自动恢复能力的高可用

分布式存储系统高可用的重要性

1、业务快速发展的支撑

2、系统不可用、系统频繁故障、系统不稳定：用户体验差，用户留不住；精力放在系统稳定性方面；无精力响应业务功能需求；

3、系统不可用，公司品牌，形象受影响：2011年4月12日，亚马逊云计算服务EC2宕机半天

4、系统不可用，公司利益：经济损失百万刀；宕机时间==损失收入（金钱！！！）

5、没有存储系统高可用，谈其他一切都是扯淡：存储系统架构高可用的重要性

分布式存储系统如何做到高可用、高可靠

----硬件层面：机器（CPU、硬盘、内存、网卡等）

----软件层面：整体架构；操作系统、文件系统、存储系统本身、日志；冗余（Master-Slaver、Replic-Sets）

硬件：生命周期，硬件故障

软件：存储软件Bugs，软件间资源的争抢

任何时间都正常提供读写服务：7*24，机器硬件故障（CPU、内存、硬盘、网卡）；机器软件故障（OS、FileSystem、存储系统软件...）；网络划分（机器间网络隔离；网络弱可用）

硬件层面：

----企业级应用：昂贵的硬件设备；IBM的小型机、中型机、甚至大型机；EMC的存储设备；Oracle数据库

----互联网公司打法：PC级服务器（价格较低）；设备廉价；低价的PC服务器一年宕机一次是大概率事件；高强度频繁读写普通硬盘，损坏的概率更高一些；硬件可用性进一步降低

PC级服务器：条件允许，尽可能采用配置高的服务器；高可用性提高；单机数据高可用最重要：重点关注磁盘

磁盘：SATA→ SCSI → SAS → SSD，性能越来越好，价格越来越高，尽可能选用高可用的磁盘；

单磁盘可用性依然保证不了，怎么办？

1、RAID（Redundant Arrays of Independent Disks）

2、磁盘阵列

3、独立磁盘构成的具有冗余能力的阵列

4、由很多价格较便宜的磁盘组成容量较大的磁盘组

5、并行读写，提升性能

6、数据恢复能力，任意磁盘故障，可以读出数据，数据重构植入新硬盘

磁盘硬件：RAID0：数据分条；RAID1：冗余；RAID210：RAID0+RAID1；RAID01： RAID1+RAID0；RAID5：分布式奇偶校验独立磁盘

多机：存储系统多机冗余；数据存储多机冗余；保证高可用性

案例：整体架构、ChunkServer宕机；文件块数据校验；文件块拷贝；垃圾回收

软件整体架构：

高可用架构分层设计原则：1、数据服务和逻辑服务分离：数据存储、业务逻辑；2、逻辑服务和接入服务分离：业务逻辑、接入层；3、接入服务和展示服务分离：接入层、数据展示

分层服务功能单一：数据、逻辑、接入、展示…

分层间低耦合：接口交互

分层内高内聚：功能聚焦单一

软件日志：日志记录（Commit Log、Bin Log）、避免操作丢失、用于数据恢复

软件：数据存储层冗余（数据多个副本；数据的高可靠性；从而实现访问的高可用性）

如何实现数据存储层的冗余？基于日志；Master-Slaver（主从机制）；Replic-Sets（具备自动恢复，提升从节点，选举主节点的机制，paxos协议）；业务层双写；…

数据复制：基于日志，MS架构，应用只写一份数据，M同步到S，Master-Slave（MySQL、 MongoDB ）；Replic Set（MongoDB）

双写：存储层多主对等结构；数据模块层对存储层双写；较灵活；数据模块层成本较高

不合理：高可靠、高可靠暴露给应用程序来写

数据备份：数据冷备份；数据热备份

数据冷备份：古老而有效的数据保护手段；将数据复制到某种存储介质上（磁盘等）；系统存在故障，从冷备份设备中恢复数据

优点：简单、廉价；成本和技术难度都较低

缺点：定期备份；数据一致性保证不了；恢复时间长，系统高可用保证不了

数据热备份：online备份；提供更好的高可用性；异步热备份；同步热备份

异步热备份：多份数据副本写入异步完成；应用程序写入成功一份数据后，即返回；由存储系统异步写入其他副本

同步热备份：多份数据副本写入同步完成；应用程序收到所有副本的写入成功；应用程序收到部分服务的写入成功，可能都成功了（网络故障无法返回写入成功响应）；为了提高写入性能，应用程序并发写入数据；没有主从之分，完全对等；响应延迟是最慢的那台服务器，而不是所有响应延迟之和

数据备份管理系统：

数据存储层失效转移机制：

失效确认：是否宕机；心跳

访问转移：访问路由到非宕机机器；存储数据完全不一致

数据恢复：Master-Slave；日志；…

示例：

整体架构：

1、Master Server：主要负责对元数据进行管理，包括名字空间；文件到文件块的映射，文件块到chunk server的映射；

2、Chunk Server：负责管理文件块的IO操作；根据Master Server的指令对文件块进行新建、删除和复制操作；

3、Client：为应用端提供文件操作接口；包括文件的创建、追加、读取、删除等操作

ChunkServer宕机：

1、Chunk Server廉价机器，宕机成为一种常见；

2、Chunk Server与Master Server之间通过HeartBeat机制来通知其状态

3、需要将该Chunk Server上所拥有的文件块拷贝到其他Chunk Server上，维护用户指定的文件块拷贝数，以保证数据的可用性

4、定期运行的监控线程会将该Chunk Server上的所有文件块加入到克隆队列中

5、克隆线程随后即开始克隆该Chunk Server上所有的文件块到其他的Chunk Server上

6、在克隆的过程中，该Chunk Server可能又恢复正常。此时，监控线程会将克隆队列中未进行克隆的，属于该Chunk Server的文件块移除，不需要再克隆。而已经克隆成功的块，将取代原有的块

文件块数据校验：

1、由于组成系统的成百上千台Chunk Server可能包含数千个磁盘，在数据频繁读写的情况下经常会发生磁盘损坏而导致数据的完整性遭到破坏，因此每台Chunk Server都会通过数据校验的方式来发现已损坏的数据；

2、当然我们可以通过在其他Chunk Server上的文件块备份来恢复数据，但是要在两个Chunk Server之间进行文件块的比较操作显然是不合实际的

3、基于校验和来对其拥有的文件块数据完整性进行验证；

4、系统会对每64KB的数据生成32位的校验和，并将其存储到本地文件；

5、当客户端或其他的Chunk Server从该Chunk Server上读取数据时，它首先会对要读取的数据进行验证，从而保证不会将已损坏的数据返回。一旦在验证时出错，则向请求端返回错误信息，并向Master Server报告。请求端收到错误消息后会向另一个文件块拷贝读取数据，而Master Server对该文件块进行重新拷贝，当新的文件块生成后再通知Chunk Server将已损坏的文件块删除

6、在Chunk Server空闲的时候，还会对那些处于非激活状态的文件块进行验证，一旦发现坏块，Master Server可以及时地创建新的文件块备份

文件块拷贝：

1、在Chunk Server发生宕机，报告坏的文件块，文件块的拷贝数不足，客户端发生读写错误等情况时，就需要对文件块进行拷贝

2、Master Server中有一个单独的拷贝管理线程存在，该线程维护一个队列，该队里中存放需要进行拷贝的文件块信息。同时克隆管理线程管理多个拷贝线程，拷贝线程的数量可以由配置文件进行配置。拷贝管理线程将任务（待克隆的文件块）下发给各个拷贝线程，执行文件块的拷贝任务

3、拷贝队列是一个优先级队列，Master Server根据多个因素来评估文件块的优先级，从而决定哪些文件块将被优先拷贝；

4、评估的因素包括：该文件块所剩余的拷贝数，该文件块是否有客户端在等待读写，该文件块损坏了几个拷贝，该文件块在过去的一段时间内被读写的次数

垃圾回收机制：

1、当一个文件被删除时，系统会立即将该操作记录到日志文件。但是系统并不会立即将该文件删除，而是将该文件通过特殊的标记重命名。系统会对这些带有特殊标记的文件进行定期扫描，如果该文件已经超过预先设置的时间段（比如24小时，可以在配置文件中设置），系统才会真正将该文件删除。在该时间段内，文件仍然可以通过该特殊的文件名访问，如果要恢复该文件，只需要简单的将文件名改成一般的文件名即可。

2、系统提供的文件延迟删除功能保证了文件在被误删的情况下在一段时间仍然可以快速恢复

第十一讲：大规模高性能分布式存储系统之总结&展望

趋势之一：三高&系统治理：高性能性、高可靠性、高可用性、高扩展性、访问透明性、服务高治理（自动恢复、自动降级等）

趋势之二：去中心化体系结构

体系结构分类：中心化、联邦化（多中心）、去中心化（每个节点都是对等的）

中心化：一个中心节点，MetaData，性能瓶颈

联邦化：多个中心节点，垂直划分、水平划分、MetaData，性能瓶颈

去中心化：无中心节点（分布式、节点）分布式哈希表，节点对称，client和任何一个节点交互都OK

中心化结构与去中心化体系结构比较

中心化优点：结构简单，查询效率高，一致性管理方便

中心化缺点：存在访问的“热点”现象，单台服务器会形成瓶颈，容易造成单点故障，单点故障会影响整个系统的可用性

去中心化优点：消除了单点故障，可用性高；可扩展性高

去中心化缺点：依赖节点间的网络通讯，交换机故障所导致的分割，依然会造成故障，一致性管理复杂

趋势三：存储虚拟与云存储：数据量越来越大，对存储提出更高的要求；如何应对这些挑战？

虚拟化是基础；云存储：私有云、公有云