浅析分布式存储系统的架构之一

这篇文档可以说是学习google的关于分布式存储的论文的学习心得。google 关于分布式存储的论文主要有三篇：

• gfs
• bigtable
• spanner

关于分布式系统的架构，google可以说是给我们开了先河，打开了脑洞。以至于后来的分布式存储系统都是此种架构，或者说是此种架构的变形。

新架构

我现在说的存储系统的架构，就是google的gfs分布式文件系统论文中所讲述的架构(主要是因为bigtable,spanner架构都是类似的)。
架构主要分为：

• 客户端
• master server
• trunk server

传统架构

之前我们所使用的结构（传统架构，老架构，或者旧架构）都是

• 客户端
• 服务端server

在单机可容存储量之下，这种结构是没有问题。我们来分析一下这种结构的弊。

当业务数据增加到单机无法容纳的情况下，如何处理呢？

当单机无法容纳时，则最直接的想法，就是将其分拆为两个机器存储。业务数据再增加，则同样的再增加机器即可。但是这带来了另外一个问题。

数据分拆之后，客户端如何获取数据？

为了解决这个问题，在以阿里为代表的公司帮我们提供了一系列的解决方案，主要的思路主要分为两类，一类是将获取数据逻辑增加到client端中（代表应用tddl)；一类是将获取业务数据的逻辑通过在client端与服务端server之间的代理层中(代表应用mycat).但这种解决方案都是很优美。

数据分拆之后，如何解决高可用问题。

为了解决这个问题，在传统的架构中，基本都是使用代理，反向负载均衡来进行后面服务的保活来解决高可用问题。比如引进haproxy,lvs等软件。但是这样对于整个系统的架构的复杂度也是在逐步增加的。

如何解决系统的高性能？

数据分拆之后，存储在多个系统中，对于高性能这个问题如何解决？如果数据只存储一份，对于数据的查询能力是有上限的，当然也无法解决系统的高可用问题。所以对于同样数据需要存储多份，这样可以通过负载均衡解决数据读方面的性能。

那么对于数据的写性能，即使是分片了，也是提高不是很大（这个是基于关系数据存储模型）。

数据存储多份又带来两个问题。

数据如何分拆？

数据的分拆基本都是根据业务特征进行分拆，与业务紧密相关。这是否是唯一的解决方法呢？答案应当是否定的。

多份数据副本如何保证数据一致？

这个问题一直都没有得到很好的解决。对于raft 协议，paxos都没有很好的应用。

未完待续…