分布式系统架构fastDFS与RPC中间件的区别

最新推荐文章于 2024-07-01 17:26:20 发布

wd521521

最新推荐文章于 2024-07-01 17:26:20 发布

阅读量1k

点赞数

分类专栏： java语言，框架文章标签：分布式

java语言，框架专栏收录该内容

8 篇文章 0 订阅

订阅专栏

分布式系统的架构思路

一、前言

在计算机领域，当单机性能达到瓶颈时，有两种方式可以解决性能问题，一是堆硬件，进一步提升配置，二是分布式，水平扩展。当然，两者都是一样的烧钱。
今天聊聊我所理解的分布式系统的架构思路。

二、分布式系统的两种方式

平时接触到的分布式系统有很多种，比如分布式文件系统，分布式数据库，分布式WebService，分布式计算等等，面向的情景不同，但分布式的思路是否是一样的呢?

1.简单的例子

假设我们有一台服务器，它可以承担1百万/秒的请求，这个请求可以的是通过http访问网页，通过tcp下载文件，jdbc执行sql，RPC调用接口…，现在我们有一条数据的请求是2百万/秒，很显然服务器hold不住了，会各种拒绝访问，甚至崩溃，宕机，怎么办呢。一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担1百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。这种方式我们称之为水平扩展。如何实现请求的平均分配便是负载均衡了。

另一个栗子，我们现在有两个数据请求，数据1 90万，数据2 80万，上面那台机器也hold不住，我们加一台机器来负载均衡一下，每台机器处理45万数据1和40万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分。

水平扩展和垂直拆分是分布式架构的两种思路，但并不是一个二选一的问题，更多的是兼并合用。下面介绍一个实际的场景。这也是许多互联网的公司架构思路。

2.实际的例子

我此时所在的公司的计算机系统很庞大，自然是一个整的分布式系统，为了方便组织管理，公司将整个技术部按业务和平台拆分为部门，订单的，会员的，商家的等等，每个部门有自己的web服务器集群，数据库服务器集群，通过同一个网站访问的链接可能来自于不同的服务器和数据库，对网站及底层对数据库的访问被分配到了不同的服务器集群,这个便是典型的按业务做的垂直拆分，每个部门的服务器在hold不住时，会有弹性的扩展，这便是水平扩展。

在数据库层，有些表非常大，数据量在亿级，如果只是纯粹的水平的扩展并不一定最好，如果对表进行拆分，比如可以按用户id进行水平拆表，通过对id取模的方式，将用户划分到多张表中，同时这些表也可以处在不同的服务器。按业务的垂直拆库和按用户水平拆表是分布式数据库中通用的解决方案。

三、负载均衡

前面我们谈到了分布式来解决性能问题，但其附带的问题是怎么分布，即如何负载均衡。这里要解决的问题是当客户端请求时，应该让它请求分布式系统中哪一台服务器，通常的做法是通过一台中间服务器来给客服端分配目标服务器。

这里同样拿两个不同的分布式系统做说明，下图左边是分布式文件系统FastDFS,右边是一个用于分布式的RPC中间件。

FastDFS的一次文件下载请求过程是这样的
1.client询问tracker可以下载指定文件的storage；
2.tracker返回一台可用的storage；
3.client直接和storage通信完成文件下载。

其中tracker便是负载均衡服务器，storage是存储文件和处理上传下载请求的服务器。

而另一个RPC中间件Hedwig也是类似的
1.client询问zookeeper哪台server可以执行请求；
2.zookeeper返回一台可用server；
3.client直接与service完成一次RPC。

zookeeper是分布式系统中一个负载均衡框架，google的chubby的一个开源实现，是是Hadoop和Hbase的重要组件。

同样的在http中，常听说的nginx也是一个负载均衡服务器，它面向的是分布式web服务器。至于具体的负载均衡算法轮询，hash等这里就不深入了。

四、同步

分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。

在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。

但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。

在一致性算法中paxos算法是公认的最好的算法，chubby、zookeeper中paxos是它保证一致性的核心。这个算法比较难懂，我目前也没弄懂，这里就不深入了。

#=============================================================================

FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS服务端有两个角色：跟踪器（tracker）和存储节点（storage）。跟踪器主要做调度工作，在访问上起负载均衡的作用。

存储节点存储文件，完成文件管理的所有功能：就是这样的存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key valuepair）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。

跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。

为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。

当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。