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

上一篇文章，我们罗列了传统的存储系纺的架构，为了解决数据量大的问题，进行系统拆分而引来的一系列问题，以及如何解决这些问题。

新架构

上文已说新架构主要分为：

• 客户端
• master server
• trunk server

三部分，那么我们在些总结一下，由于系统进行拆分引入了一些问题，对于这些问题的在新架构中是如何解决如何归类，并进行系统化的。

trunk server,即真实存储业务数据的服务器。它与传统存储数据的server没有什么区别，只是在整个分布式存储系统中，单个trunk server 中存储了部分数据。它需要将数据的分布情况上报给master server服务器。

master server服务器，它存储着数据的分布情况，即哪个trunk server存储哪段数据，哪个trunk server还活着等。该服务器存储了数据的分布元数据，帮我们解决了数据如何分布的问题，以及在获取数据时路由到哪个业务数据存储服务器的问题。并一同解决了业务数据存储服务器的高可用、容错、保活、负载均衡的问题。

客户端，放在应用系统端的jar等，初始时不需要显示的连接trunk server,而是连接master server.它获取数据的逻辑，即是先询问master server,所需要的数据存储在哪个trunk server,然后再连接trunk server获取数据。而不是采用传统的代理模式。在我看来，这是最大的改变。即获取数据的逻辑的转变。但是为了支持这种转变需要在存储结构上发生很大的变化。

为了支持这种转变，新架构出现了多种数据存储结构，分布式文件，表格，kv,等存储结构。即使是现在的分布式数据库底层也是kv结构，比如spanner,tidb等。

与dubbo 对比

google 所采用的这种调用模式与我们所采用的代理模式或者改造客户端的模式均不太一样。它将我们之前的垂直调用关系，转变成三角关系；将原来客户端调用一次，变成了客户端调用两次，这个转变看似简单实例是一种质的变化。

这种结构，master server起到了一种软负载的作用。而trunk server 可以采用横向扩展，解决了存储容量的问题。在trunk server扩容时无需通知客户端，或者说客户端会自动感知的。

比如dubbo，spring cloud 也是采用这种模式。比如与dubbo对比:

gfs	dubbo
客户端	dubbo客户端
master server	注册中心
trunk server	dubbo 服务

与dubbo不同之处在于dubbo服务一般情况都是无状态的。而trunck server是一个有状态的。对于一个有状态的如何解决其容错及负载均衡问题呢？也就是分布复制如何解决一致性的问题。那么分布式一致性协议该上场了。分布式协议目前有raft,paxos,zab等，后面我们聊一下raft协议。当然关于这三者的文档、书籍论文都有很多，大家可以找来看看，也可以搬个板凳等我下文接着聊。
未完待续…