分布式数据存储系统分布式存储系统的核心逻辑是根据一个规则将用户需要存储的数据存储在另一台机器上，当用户想获取指定的数据时，根据规则将数据检索到存储数据的机器上。
如下图所示，当用户、即APP要访问数据d时，分布式操作引擎通过Hash、一致性Hash、数据范围分类等映射方法，将用户引导到数据d所属的存储节点
负责的黄蜂认为，获取数据的整个过程和你去店里买东西的过程有点相似。
当顾客去商店购物时，向导根据顾客想购买的商品引导顾客到合适的货架上，顾客从这个货架上接收要购买的商品，完成购物。 这里的客户是图中的APP，向导相当于分布式操作引擎，按照一定的规则找到相应的货架，货架是存储数据的不同机器节点。
实际上，该过程是在分布式存储系统中检索数据的典型过程，商品、导购和货架构成分布式存储系统的三个元件，分别对应于分布式区域3358www.Sina.com/
分布式数据存储系统的三要素商品：数据模型文件模型： hdfs (非结构化)关系模型：结构化键值模型：半结构化hbase、 Google bigtable read :数据位置(数据分片)还是单身的分片按顺序平铺货架)数据存储引擎还是单身的站点存储引擎b树存储引擎LSM树存储引擎分布式系统的基本不可避免地从独立APP应用向分布式APP应用的转变，必然会引入网络因素，但由于网络本身的可靠性低，分布式系统的通信也不可靠。 另外，由于分布式系统由多个廉价的机器节点构成，所以其服务器节点也同样不可靠。 举个极端的例子，一个集群构成360台机器，如果平均一台机器每年故障一次，该集群几乎不可用。 因此，请参阅数据（生产者 / 消费者）、数据索引和数据存储引擎
分布式系统带来的问题：数据一致性分布式系统要解决的另一个中心问题是自动容错(高可用性)，那么分布式数据存储如何解决这个问题呢？
答案是复制(数据的复制)。 通过将一个数据复制到多个副本，并在一个副本所在的存储节点发生故障时，分布式存储系统自动将服务切换到另一个副本，实现自动容错。 但是，这也带来了另一个问题，即如何确保多个副本之间的数据完整性。
为了了解数据的一致性，如上所述，由于存在异常，分布式数据存储系统将存储多个数据。 复制副本被认为是分布式存储系统解决自动容错的唯一手段。 但是，复制会带来数据完整性问题。 如何理解数据的完整性呢？
首先，从两个角度理解数据的一致性。
第一个角度是用户或客户端(即客户端)的读写操作是否符合某些特性，第二个角度是存储系统。 这意味着存储系统的多个副本是否匹配，更新顺序是否相同。
从存储系统的角度看，数据一致性对于存储系统来说，一致性是指同一事务处理之后多个副本之间的数据是否一致。 这是因为，例如客户端向某个分布式系统提出更新操作(相同的事务)，分布式系统在执行更新操作并响应用户后，保存在所有节点上的数据是一致的。
另一个含义是更新顺序的一致性。 存储系统的多个副本之间的更新操作是否以相同的顺序进行。
从存储系统的角度看，一致性存在以下两种情况：
一致：在一个事务中，主片数据与副本中的数据匹配。 同步复制多节点写入raft (Pax OS ) leader选举、日志复制(Zab最终一致性)异步复制，当主数据在一个事务中发生更改时返回客户端，数据由于同步复制对性能有很大的影响，因此存储系统通常只需要最终的一致性。 例如：
mysql传统的主从集群redis哨兵集群等对一致性要求不高，在金融业务涉及金钱的情况下，对一致性要求高就必须使用强一致性。 例如：
Mysql3节点企业级复制(阿里巴巴云)是raft协议MySQL公式的组复制(mgr )方案对于客户端来说，完整性是指如果http://ww.Sisi写入成功，则其他读取操作可以读取最新写入操作的结果。
从客户端的角度看，一致性有以下三种情况。
一致性强：确保最新读取弱的一致性：不确保最新读取的最终一致性：确保最终进行最新读取。 在这种情况下，客户端读取方法具有不同的效果，因为主数据和副本数据、副本和副本之间的数据可能不同。 这些不同的读取方法形成了最终一致性的变体。 读写(Read-your-writes )一致性)读取自己的写操作，自己写的数据全部从主库读取，其他人写的数据全部从库中读取。 会话一致单调读取：每个用户始终从同一个节点读取。 不同的用户可以从不同的节点读取。 从客户端的角度看，单调写入必须支持存储系统的读写一致性、会话一致性、单调读取和单调写入等特性。
场景很难理解上面的概念，所以举例说明。
首先，定义以下场景
， 存储系统：分布式存储系统，有数据K，K有k1、k2两个副本，副本复制使用异步复制。客户端A、B、C相互独立，均可对存储系统做读操作和写操作可能出现的场景（从客户端的角度看）如下：
强一致性： 定义：假如A先写入了一个k的值到存储系统，存储系统能够保证后续的A、B、C的读取都返回最新值。
实现方式：我们发现，由于存储系统采用了异步复制（存储系统放弃了强一致性，保留了可用性），为了实现强一致性，对于某个数据（k或者主键），客户端读写操作都必须在同一台机器上，这个时候，对于客户端来说是强一致性的。但是，读写都在同一个分片上，那副本的价值体现在哪呢？这个时候，副本的价值只体现在高可用上面，如果主分片所在的机器节点挂了，系统会在副本中选一个升级为主分片，继续提供服务。
实现这种强一致性的数据库有：
hbase hbase的一致性详解redis 哨兵集群：可能你会疑惑，上面说到redis哨兵集群对存储系统来说是最终一致的，但是因为客户端始终连接的是master节点，所以，对于客户端来说，redis哨兵集群是强一致性的。hbase的每个值只会出现在一个region中（咋一看，hbase没有数据副本？），而region的存储实例HFile是存在于hdfs的，hbase的自动容错依赖于hdfs。当某一个RegionServer崩溃时，master会将这个rs上面的所有region分配给其他rs（因为region的数据存储在hdfs上，分配动作比较轻量级），继续提供服务。
弱一致性：假如A先写入了一个值到存储系统，存储系统不能够保证后续的A、B、C的读取都返回最新值。
这种情况很麻烦，一般不会选择这种场景。
最终一致性：最终一致性是弱一致性的一种特例。假如A先写入了一个值到存储系统，存储系统能够保证，A、B、C的读取操作“最终”都会读取到A所写入的最新值。“最终”一致性有一个“不一致窗口”的概念，它的大小取决于交互延迟以及复制协议要求同步的副本数。
实现最终一致性的数据库有：
主从复制的mysql集群，写主读从的情况。elasticsearch，写操作在主分片，读操作所有分片，所以可能出现主分片的数据还没有复制到副本分片的情况。综上我们看出，对于大数据领域的大数据存储系统，因为数据量大，对性能的要求比较高，一般都会采用最终一致性。
CAP理论根据CAP理论，我们知道在满足P（分区容错性）的情况下，C（强一致性）与A（可用性）只能二选一。
选CP策略放弃A： hbaseredis哨兵集群Mysql 三节点企业版zookeeper当master挂掉，需要选举新的master。这段时间系统是不能提供服务的。
选AP策略放弃C： Cassandraelasticsearchmysql传统主从集群 分布式一致性算法首先，这些算法解决什么问题？
在分布式系统中，为了保证数据的高可用，通常我们会将数据保留多个副本，这些副本会放置在不同的物理的机器上。副本要保持一致，那么所有副本的更新序列也要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作，到底哪个客户端先做，哪个客户端后做，更新顺序要保证。
但是，在分布式环境中，网络是不可靠的，通信是不可靠的。比如说，数据库的主从拷贝，如果有一个副本的数据更新失败，那么在一个分布式系统中聚会出现两个不一致的值。分布式一致性算法就是为了解决这类问题。
Paxos Paxos通俗解释Raft raft动画详解Zab 分布式数据存储系统的架构设计 数据存储引擎数据存储引擎是存储系统的发动机，直接决定了存储系统的性能与功能。存储引擎的基本功能有：增、删、读、改，其中读取操作又分随机读和顺序扫描。
存储引擎增删改随机读取顺序扫描读写特征数据库还单身的犀牛存储引擎支持支持不支持读写均很快redisB+树存储引擎支持支持支持读快写慢mysqlLSM树存储引擎支持支持支持读慢写快hbase、levelDB存储引擎性能对比 还单身的犀牛存储引擎还单身的犀牛存储引擎是还单身的犀牛表的持久化实现，通过还单身的犀牛函数直接定位到key的位置，所以随机读写很快，但是不支持顺序扫描。
B+树存储引擎具体讲解可以参考 B+索引
我们只要知道，当写比读多时，LSM树相比于B+树有更好的性能，因为随着insert操作，为了维护B+树结构，节点分裂，时间复杂度相比读取更高一些，并且读磁盘的随机读写概率也会变大，性能会逐渐减弱。
LSM树存储引擎LSM树本质上和B+树一样，是一种磁盘数据的索引结构。但和B+树不同的是，LSM树的索引对写入请求更友好。因为无论是何种写入请求，LSM树都会将写入操作处理为一次顺序写。
LSM树的索引一般由两部分组成，一部分是内存部分，一部分是磁盘部分。内存部分一般采用跳跃表来维护一个有序的KeyValue集合。磁盘部分一般由多个内部KeyValue有序的文件组成。
简单地说，LSM 的设计目标是提供比传统的 B+ 树更好的写性能。LSM 通过将磁盘的随机写转化为顺序写来提高写性能。
数据分布分布式系统与单机系统的主要区别在于能将数据分布到多太机器上去，并在多台机器之间实现负载均衡。
数据分布的方式主要有两种：
还单身的犀牛分布 普通还单身的犀牛一致性还单身的犀牛还单身的犀牛槽 顺序分布：将每张表的数据按照主键排序，再进行分割，每台机器分配一定范围的数据。 负载均衡负载均衡是分布式系统的必备功能，多个节点组成的分布式系统必须通过负载均衡机制保证各个节点之间负载的均衡性，一旦出现负载非常集中的情况，就很有可能导致对应的部分节点响应变慢，进而拖慢甚至拖垮整个集群。
在实际生产线环境中，负载均衡机制最重要的一个应用场景是系统扩容。分布式系统通过增加节点实现扩展性，但如果说扩容就是增加节点其实并不准确。扩容操作一般分为两个步骤：首先，需要增加节点并让系统感知到节点加入；其次，需要将系统中已有节点负载迁移到新加入节点上。第二步负载迁移在具体实现上需要借助于负载均衡机制。
在分布式数据库的设计中，负载均衡主要体现在数据上，数据的分布，数据本身的读写负载。比如，hbase级就有两种策略：SimpleLoadBalancer策略和StochasticLoadBalancer策略。
SimpleLoadBalancer：保证每个RegionServer的Region个数基本相等StochasticLoadBalancer：StochasticLoadBalancer策略相比SimpleLoadBalancer策略更复杂，它对于负载的定义不再是Region个数这么简单，而是由多种独立负载加权计算的复合值，这些独立负载包括： Region个数Region负载读请求数写请求数Storefile大小 一致性与可用性上面的CAP理论我们都知道，在满足P的情况下，CA只能选择一个。
如果采取强同步复制，保证了存储系统的一致性，然而，当主备副本之间出现故障时，写操作将被阻塞，系统的可用性无法得到满足。如果采用异步复制，虽然保证了存储系统的可用性，但无法做到强一致性。
存储系统设计时需要在一致性与可用性直接做权衡。例如，现在大多数的分布式系统的数据复制都有三种模式可选：
最大保护模式：强同步复制模式，写操作要求主库同步复制至少一个备库才返回客户端。最大性能模式：异步复制。最大可用模式：上面两种模式的折衷。正常情况下相当于最大保护模式，如果主备之间出现网络问题，则切换成最大性能模式。 hbase强一致性的特殊性这里特别介绍一下hbase，hbase的底层数据存储依赖hdfs，并且hbase的同一个数据只会出现在一个region。hbase数据的容错依赖hdfs的多副本。
自动容错集群规模越大，故障发生的概率就越大，当集群的规模大到一定程度，故障基本每天都会发生。所以，自动容错是分布式存储系统设计的重要目标。
想要做到自动容错，首先要先发现故障，然后再将错误节点的数据迁移到其他正常的节点。所以，自动容错包含两部分：
故障检测：故障检测使用租约（Lease协议） 分布式系统理论之租约机制学习故障恢复：当master检测到datenode发送故障时，会将服务迁移到其他正常的datenode。 hbase的读写流程 hbase的寻址流程 hbase的meta结构 Region写入流程