请说一下你对分布式存储系统的理解？_分布式存储 csdn

为什么需要分布式存储?

在我们平时的业务开发中，常见的存储方式就是关系型数据库，比如：MySQL或PostrageSQL。那么如果数据量非常的大呢？比如有200TB的数据该怎么存储呢？这个时候关系型数据库就不是好的选择方案了。就需要分布式存储系统登上舞台了。还拿刚才的例子来说，有200TB的数据，那么我们可以申请20台机器，每台机器负责存储10TB的数据，那么这种分而治之的解决方式就可以应对互联网中大容量数据的存储。那么除了分开存储的方式之外，我们日常所设计的分布式存储系统都有一个通用的特点，就是易于扩展。现在我们针对200TB申请了20台机器，如果数据量达到2000TB呢？我们要申请200台机器呢？如果对于这种横向扩展不能很方便的支持的话，那么是不符合针对海量数据的扩展支持的。

什么是分布式存储系统?

上面我们已经将数据拆分到了20台机器上，那么这20台机器中运行的实例谁来管理和控制呢？总不能各自跑各自的吧？那么这时候，我们就需要分布式存储系统来帮忙了。它可以负责把分散在多台机器上所存储的数据进行统一管理。比如我们常说的Hadoop或FastDFS；其实这种思想是普遍被应用的，比如KafKa，Elasticsearch，HBase等等。

那么它是怎么管理多个节点的呢？我们假设一共有60T的数据，分别是20T的用户数据，20T的商品数据和20T的评论数据，那么要分散存储在3台机器上，如下所示：

如果用户要获取商品数据，那么请求会发送到master节点，然后通过master找到机器C中是存储了20T的商品数据，那么请求发送到机器C，从机器C中查询用户所需要的数据，然后返回给用户。

集群中节点挂了怎么办?

但是在整个集群的存储方案中，如果机器C由于某种原因挂掉了。整个机器C中存储的所有数据都无法被访问了怎么办呢？那么用户如果此时再来获取商品数据岂不是什么都无法获得了？那么针对这个问题就需要副本冗余机制了。

那么什么是副本冗余机制呢？怎么进行冗余呢？因为现在的用户数据、商品数据和评论数据都只有一份，那么既然三台机器，我们就把数据扩展为三份，并且为了应对机器挂掉数据丢失不可用，我们要把三个副本分别放到这三台机器上。如下图所示：

那么这个时候，加入还是机器C挂掉了，用户再次来获取商品数据的时候，就可以从机器B或者机器D中获得全量的数据。但是，问题还是没有解决，就是用户请求获取商品数据的时候，请求到了Master节点，但是Master节点中的Slave列表中依然是有机器C的啊，如果这个请求转发到机器C去获取数据，那么由于机器C是宕机状态，依然还是无法避免问题的发生啊？那怎么办呢？那么就需要实现一种机制了，任意一台机器宕机，都需要让Master节点知道才可以。

Master对节点如何监控?

还是继续上面的例子，如何让master能知道它所管理的salve哪些是健康的？哪些是宕机不可用了呢？那么针对这个问题，我们常用的是心跳机制，也就是说，每个slave每个一定时间（例如：30秒）请求一次master，告诉master——“我还活着呢！”，那么master就知道了slave的存活状态了，如果某个slave宕掉了，它就无法发送心跳，那么如果master发现某个节点没有发送心跳，那么就判断这个节点已经死去，就将它从服务列表中删除掉。那么用户后面再来请求商品数据的时候，就只会去机器B或机器D上面获取了。如下图所示：

副本管理

那么我们通过心跳可以判断机器的健康状态，但是那台机器上的副本相当于“丢失了”，但是我们在做配置的时候，配置了数据的副本是3个，那怎么办呢？其实在实际环境中，我们的机器会很多，比如有20台机器，那么当我们配置副本数为3的时候，会随机找3台机器去存放副本，如果像上面的情况发生，副本数变成2个了，那么会在剩余存活的机器中，在复制出一个副本，将副本数依然维护成3个。

那么如果机器C又恢复了呢？并且机器C上面的数据并没有丢失，那么岂不是商品的副本数变为4了个？那么这个时候，就需要执行副本删除了。那么当master收到了机器C的心跳请求后，会发送一个删除该机器商品数据副本的任务，那么机器C中的salve就会执行副本删除。这样，商品的副本数总数就依然保持为3个了。