转载自： https://砖局域网. zhi Hu.com/p/103851491
在前一篇文章“数据存储技术：独立篇”中，我们调查了数据在独立中是如何存储的。
如果需要保存的数据量太大，无法保存到一台计算机的磁盘上，则必须将这些数据保存到多台计算机上。
数据分布将数据分布到不同节点的方法如下：
ajdyc分布:例如，对数据的每个主键进行一致的ajdyc分布
顺序分布:每个主键将数据划分为规则范围，每个规则范围的数据存储在一个节点
根据ajdyc/顺序范围，负载均衡分布分布式存储系统自动识别负荷高的节点(机器Load值、CPU、内存、磁盘、网络、QPS、线程等资源利用率)及其服务的一部分
分布式存储系统中的每个群集通常都有一个总管理节点。 通过主节点调度实现负载均衡：工作节点通过心跳包(Heartbeat )向主节点发送节点负载的相关信息； 主节点计算工作节点负载和需要迁移的数据，生成的迁移任务放入迁移队列等待执行。 虽然很多人可能认为总控制节点会成为分布式系统的瓶颈，但是任务P2P体系结构(无中心节点)体系结构更有利。 然而，情况并非如此。 许多主流分布式存储系统都包括总管理节点，因为总管理节点体系结构使维护变得更加容易，并且可以支持数千万个群集规模。 稍后我们将讨论总控制节点瓶颈问题的优化。
主节点主要用于全局调度、元数据管理(例如，分片位置信息)。
当然，还有许多存储系统没有中心体系结构，例如Redis
http://www.Sina.com/http://www.Sina.com /
在分布式存储系统中，随着群集规模的增长，出现故障的概率也随之增加。 大规模集群每天都发生故障，其中发生故障的概率最高的是单体故障、磁盘故障。
为确保分布式存储系统的可靠性和可用性，必须在多个复制副本中备份每个节点上的数据。
主副本通常只有一个，可以提供读写服务；
备份拷贝(Backup )可以有多个，提供不对外服务/只读服务。
如果主副本出现故障，则必须将备用副本设置为新的主副本。 此操作将变为“选举”。
新的主副本的选举可使用主节点的租赁合同、分布式锁、Paxos合同等选举合同(典型例： ZooKeeper )等来进行。 主副本之间的数据复制主要通过同步操作日志(Commit Log )实现。 主副本首先将操作日志与准备副本同步，准备副本再现操作日志，并在完成后通知主副本。 (关于操作日志，可以阅读更多《数据存储技术：单机篇》 )
分布式存储系统使用复制协议将数据同步到多个存储节点，以确保多个副本之间的数据一致性。
有两种类型的复制协议：强同步复制和异步复制。
数据节点高可用如果有多个备份副本，则至少需要同步到一些备份副本。
虽然可以确保主复制副本之间的一致性，但是如果复制副本发生故障，存储系统的正常写入服务可能会被阻止，从而影响系统的可用性
数据备份/复制如果本地修复成功，主副本就可以通知客户端写入成功，而无需等待备份副本的响应。 另一方面，主副本使用异步机制(如另一个复制线程)将客户端更改操作推送到另一个副本。
可用性相对较好，但无法保证主复制副本之间的数据一致性。 如果主复制副本发生不可恢复的故障，最后一次更新操作可能会丢失。 根据CAP原理，一致性和可用性是矛盾的。 在设计存储系统时，需要在一致性和可用性之间进行权衡。 根据实际需要，可以选择以下模式：
强同步复制:这意味着它是一个强同步复制协议。 主副本数据具有一致性，但可用性为异步复制:异步复制协议。 性能和可用性得到保证，但可能会丢失数据。最大保护模式通常相当于最大保护模式； 主站之间的网络发生故障时，切换到最大性能模式。 该模型在一致性和可用性之间进行了良好的权衡。最大性能模式
在数据备份中，存储节点通常分为多个组，每个组中的节点处理完全相同的数据。 其中一个是主复制副本节点，另一个节点是复制副本备用磁盘。
由于同一组中的节点服务相同的数据，因此这样的系统将是同构的。
最大可用模式
同构复制假设每个存储节点处理1TB的数据，内部传输带宽限制为20MB/s秒，添加复制节点所需的数据复制时间为1TB/20MB/秒=550 由于在数据复制过程中存储节点很可能再次出现故障，因此这种体系结构很难实现自动化，并且不适用于大型分布式存储系统
。异构系统将数据划分为很多大小接近的分片，每个分片的多个副本可以分布到集群中的任何一个存储节点。如果某个节点发生故障，原有的服务将由整个集群而不是某几个固定的存储节点来恢复。由于整个集群都参与到该故障节点的恢复过程，所以故障恢复时间很短；并且集群规模越大，优势就会越明显。
数据节点故障检测与恢复
系统检测到故障出现时，自动使用备份数据进行故障恢复。
基于总控节点的故障检测与恢复：
心跳机制：总控节点每隔一段时间，比如1秒，向工作节点发动一个心跳包。如果工作节点没有发生故障，则可以正常响应总控节点的心跳包；否则，总控节点在重试一定次数都没有收到工作节点的响应后，则会认为该工作节点发生了故障。心跳机制的问题：总控节点没有收到工作节点的心跳响应，并不能确定工作节点发生故障并停止了服务。在系统运行过程中，可能发生各种错误，比如网络故障、工作节点过于繁忙而导致无法响应心跳包。由于总控节点判断工作节点发生故障后，往往需要将该工作节点上面的服务迁移到集群中的其他服务器，为了保证强一致性，需要确保没有响应心跳包的工作节点不再提供服务，否则将出现多台服务器同时提供同一份数据的服务而导致数据不一致的情况。租约机制：在机器之间的本地时差相差不大的前提下（实践中，机器之间会进行时钟同步），所以可以通过租约（Lease）机制进行故障检测，避免心跳机制的问题。租约机制就是带有超时时间的一种授权。总控节点可以给工作节点发放租约，工作节点持有的租约在有效期内才允许提供服务，否则主动停止服务。工作节点的租约快要到期的时候，需要向总控节点重新申请租约延期。若工作节点出现故障或与总控节点之间的网络发生故障时，其租约将过期，从而总控节点能够确保该工作节点不再提供服务（由于机器之间的时钟有误差，若租约有效期为10秒，则总控节点判断工作节点故障的时间需要加上一个前提量，比如11秒时，才可以认为该工作节点租约过期），其服务可以被安全地迁移到其他服务器。基于分布式锁选主：
主备副本工作节点共用争夺同一个分布式锁，争取到分布式锁的节点作为主副本主副本工作节点故障后，自动释放分布式锁；其他备副本可以重新争夺到分布式锁成为主副本，对外提供服务分布式锁也需要实现高可用，常用的高可用协调服务有：Apache ZooKeeper、Google Chubby等使用例子：跨机房部署，当主机房发生故障时，除了手工切换到备机房，还可以采用分布式锁服务实现自动整体切换。
集群选主协议自恢复：
在主备副本节点之间构成一个集群，实现自选举协议实现参考：ZooKeeper集群中的各个节点基于Paxos选举协议实现数据强一致性和集群高可用性优点：总控节点和工作节点之间不需要保持租约，总控节点出现故障也不会对工作节点产生影响缺点：工程实现复杂 总控节点高可用总控节点备份
除了工作节点需要通过数据备份、故障自动检测与恢复实现高可用外，总控节点自身也同样需要实现高可用。
主控节点也需要集群部署，集群选主也可以通过心跳租约、分布式锁等方式实现：
总控节点瓶颈
内存瓶颈：
为了快速响应请求，总控节点需要维护所有数据节点的元信息在内存中。随着节点的增多，内存容量可能会成为性能瓶颈解决方式：在总控机与工作机之间增加一层元数据节点，每个元数据节点只维护一部分而不是整个分布式存储系统的元数据；这样总控节点只需要维护元数据节点的元数据即可。QPS瓶颈：
如果客户端每次访问数据前，都要先请求主控节点获取路由信息，则总控节点QPS可能会变得很高解决方式：客户端本地缓存一份路由信息；可以每隔一段时间 / 当总控节点中的路由信息更新时，再更新本地缓存 分布式存储系统范型分布式文件系统
主控节点需要保存文件目录元数据信息；文件被拆分/合并为固定大小的数据分片，分布式异构保存在数据节点中。
大文件：拆分成固定大小的数据块，作为备份分片（比如Google File System里的chunk）小文件：合并成一个大文件数据块，作为备份分片（比如Taobao File System里的block）Google File System
Taobao File System
分布式键值系统
数据分布一般采用一致性ajdyc
淘宝Tair
中心控制节点：Config Server，采用一主一备的形式保证可靠性数据服务节点：Data ServerConfig Server负责管理所有Data Server，维护其状态信息和数据分布策略；Data Server对外提供各种数据服务，并以心跳的形式将自身状况汇报给Config ServerRedis
Redis采取的是无中心化架构
分布式：Redis Cluster
数据分区：Redis Cluser采用虚拟槽分区（一致性ajdyc的一种优化）请求路由：在集群模式下， Redis接收任何键相关命令时首先计算键对应的槽， 再根据槽找出所对应的节点， 如果节点是自身， 则处理键命令；否则回复MOVED重定向错误， 通知客户端请求正确的节点。节点通信：采用P2P的Gossip（ 流言） 协议，节点彼此不断通信交换信息， 一段时间后所有的节点都会知道集群完整的信息高可用：Redis Sentinel
保证Redis节点的故障发现和故障自动转移分布式数据库
分布式数据库（分库分表）可以在应用层实现，也可以在中间件层实现。
中间件层实现的好处是对应用透明，应用就像查单库单表一样去查询中间件层；缺点是除了维护中间件外，还要考虑中间件的HA/负载均衡等，增加了部署和维护困难。应用层实现可以在JDBC驱动层、DAO框架层，如MyBatis/Hibernate上完成，如当当的sharding-jdbc是JDBC驱动层实现，阿里的cobar-client是基于DAO框架iBatis实现。MySQL Sharding
中间件层实现
Sharding JDBC
应用层实现
大数据存储
Hadoop大数据家族的底层存储，主要使用的是HDFS文件系统。
HDFS的关键组件有两个，一个是DataNode，一个是NameNode
DataNode负责文件数据的存储和读写操作，HDFS将文件数据分割成若干数据块（Block），每个DataNode存储一部分数据块，这样文件就分布存储在整个HDFS服务器集群中。HDFS为了保证数据的高可用，会将一个数据块复制为多份（缺省情况为3份），并将多份相同的数据块存储在不同的服务器上，甚至不同的机架上；即HDFS文件系统的DataNodes中存储的数据分片都是异构的。NameNode负责整个分布式文件系统的元数据（MetaData）管理，也就是文件路径名、数据块的ID以及存储位置等信息，相当于操作系统中文件分配表（FAT）的角色。**应用程序客户端（Client）**可以并行对这些数据块进行访问，从而使得HDFS可以在服务器集群规模上实现数据并行访问，极大地提高了访问速度。云存储
云存储就是通过网络，将大量普通存储设备构成的集群，虚拟化为易扩展、弹性、透明、具有伸缩性的存储资源池，以统一的接口、按需提供给授权用户；授权用户可以通过网络对存储资源池进行任意的访问和管理，并按使用付费。