Java全栈面试题汇总目录-CSDN博客

1. 什么是FastDFS？

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

2. FastDFS有哪些架构？

FastDFS架构包括Tracker server，Storage server，Client。

Tracker Server

• 主要协调调用工作，并对Storage Server起到负载均衡的作用
• 负责管理所有的storage server和group，每个storage server启动之后会链接Tracker,告知自己所属group等信息，并保持周期性心跳
• Tracker Server可以有多台，Tracker Server之间是相互平等，不存在单点故障，客户端请求tracker server采用轮询的方式，如果请求Tracker server无法提供服务，则换另外一台

Storage Server

• 主要提供容量和备份服务
• 以group为单位，每一个group里有多个storage server,数据互为备份，各个group互相独立
• 采用分组存储方式的好处是灵活和可控性强，比如上传文件，可以有客户端指定，也可以有tracker进行调度选择
• 一个组的存储压力过大，可以在改组增加存储服务器扩充服务能力，当容量不足时，可以增加组扩充容量

Client

• 上传下载的数据服务器，也就是我们部署的服务器

3. FastDFS服务端有哪些角色？

Tracker：管理集群，tracker也可以实现集群。每个tracker节点地位平等，收集Storage集群的状态。

Storage：实际保存文件Storage分为多个组，每个组之间保存的文件是不同的。每个组内部可以有多个成员，组成员内部保存的内容是一样的，组成员的地位是一致的，没有主从的概念。

4. FastDFS的存储策略？

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

在组中新增加服务器时，同步已有的文件由系统自动完成，同步完成，系统将自动将新增服务器切换到线上提供服务，当存储空间不足或消耗完时，可以动态加组，只需要增加一台或者多台服务，并将它们配置成一个新组，这样就扩大了存储系统的容量。

5. Storage状态收集？

Storage server会通过配置链接集群中所有的tracker server，定时向它们报告状态，包括磁盘空间，文件同步状态，文件上传下载次数等统计信息

storage server的7个状态

• FDFS_STORAGE_STATUS_INIT：初始化，尚未得到同步已有数据的源服务器
• FDFS_STORAGE_STATUS_WAIT_SYNC：等待同步，已得到同步已有数据的源服务器
• FDFS_STORAGE_STATUS_SYNCING：同步中
• FDFS_STORAGE_STATUS_DELETED：已删除，该服务器从本组中摘除(注：本状态的功能尚未实现)
• FDFS_STORAGE_STATUS_OFFLINE：离线
• FDFS_STORAGE_STATUS_ONLINE：在线，尚不能提供服务
• FDFS_STORAGE_STATUS_ACTIVE：在线，可以提供服务

当storage的状态是在线的时候，会向tracker发送心跳，tracker server会将其的状态改成，在线可以提供服务

6. FastDFS的交互过程是怎样的？

1. client询问tracker上传到的storage，不需要附加参数
2. tracker返回一台可用的storage
3. client直接和storage通讯完成文件上传

7. 文件上传流程？

1. tracker server收集storage server的状态信息

storage server定时向tracker server(可以多个)发送磁盘剩余空间，文件同步状况，文件上传下载次数等信息storage server会链接整个集群中所有的tracker server,向他们发送自己的状态。

2. 选择tracker server

当集群中不止一个tracker server时，由于tracker server是对等的，客户端在upload文件可以任意选择一个tracker

3. 选择存储group

当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group,支持如下选择group的规则

• 所有group轮询
• 指定某一个确定的group
• 选择空间多的group

4. 选择storage server

当选定group后，tracker会在group内选择一个storage server给客户端啊，支持如下storage的规则

• 在group中storage轮询
• 按IP排序选择
• 按优先级选择，可配置

5. 选择storage path

当分配好storage server后，客户端将向storage发送写文件请求，storage将会分配一个存储目录，支持如下规则(在storage配置文件可以通过storage-path*,可以设置多个)

• 多个存储目录轮询
• 剩余空间最多优先

6. 生成文件名

选定文件存储目录之后，storage会为文件生成一个文件名称，由源storage server IP,文件创建时间，文件大小，文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可以打印的字符串

7. 选择两级目录

当选定存储目录之后，storage会为文件分配一个file id，每个存储目录下有两级256*256的子目录，storage会按文件名称进行两次hash,路由到其中一个目录，然后将文件filed id为文件名存储在改子目录下

8. 生成file id

当文件存储到某个目录后，即认为文件存储成功，接下来就会为该文件生成一个文件id，有group，存储目录，两级目录，文件名，文件后缀名拼接而成。

8. 文件同步？

写文件时，客户端将文件写到group的一个storage server即认为文件写入成功，storage server写完文件后，会由后台线程将文件同步到同group的storage server。

每个storage写文件后，同时会写一份binlog, binlog里不包含文件数据，只包含文件名信息，这份binlog用于同步，storage会记录group内其他storage同步的进度，以便重启之后接上次的进度继续同步，进度以时间戳的方式记录，所以最好把集群内所有server的时钟保持同步。

storage的同步进度会作为元数据的一部分汇报到tracker上，tacker在选择读storage的时候会已同步进度作为参考。

比如一个group内有A、B、C三个storage server，A向C同步到进度为T1(T1以前写的文件都已经同步到B上了)，B向C同步到时间戳为T2(T2>T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1(即所有T1以前写的数据都已经同步到C上了)；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。

9. 文件下载流程？

1. tracker server收集storage server的状态信息

• storage server定时向tracker server发送磁盘空间，文件同步状况，文件上传下载次数信息等
• storage server会连接整个集群tracker server，向它们报告状态

2. 选择tacker server

• 和上传文件一样，任意选择

3. 选择可用的storage server

客户端下载download请求给某个tracker，必须带上传文件名信息，tracker会从文件名中解析group，路径信息，文件大小，创建时间，源storage server IP等信息，然后请求选择一个storage用来服务器读请求。

由于group同步是后台的一个异步线程进行，所以有可能出现在读的时候，文件还没有同步，为了避免这种情况，tacker会安装如下规则选择group可读的storage server。

• 该文件上传到的源storage，只要源storage只要存活，肯定包含这个文件，源头的地址被编码在文件名中
• 文件创建的时间即storage被同步到的时间戳，且当前时间-文件创建时间>文件同步最大时间，即文件同步后，认为经过最大同步时间后，文件肯定存在
• 文件创建时间<文件同步时间戳，即文件同步时间戳之前的文件确定已经同步
• 当前时间-文件创建时间戳>同步延迟阀值，即经过同步延迟阀值，认为文件肯定同步了

10. 新增storage server？

组内新增一台storage server A时，由系统自动完成已有数据同步，处理逻辑如下

1. storage server A连接tracker server，tracker server将storage server A的状态设置为FDFS_STORAGE_STATUS_INIT。storage server A询问追加同步的源服务器和追加同步截至时间点，如果该组内只有storage server A或该组内已成功上传的文件数为0，则没有数据需要同步，storage server A就可以提供在线服务，此时tracker将其状态设置为FDFS_STORAGE_STATUS_ONLINE，否则tracker server将其状态设置为FDFS_STORAGE_STATUS_WAIT_SYNC，进入第二步的处理
2. 假设tracker server分配storage server A同步已有数据源storage server为B，同组storage server和tracker server通讯得知新增storage server A,将启动同步线程，并向tracker server询问storage server A追加同步的源服务器和时间戳，storage server B将把时间戳之前的数据同步给storage server A，而其余的storage server从截止时间点之后进行正常同步，只把源头数据同步给storage server A,到了截止时间点之后，storage server B对storage server A的同步由追加同步改成正常同步,只同步源头数据
3. storage server B向storage server A同步完所有数据，暂没有数据同步时，storage server B请求tracker server将storage server状态设置为FDFS_STORAGE_STATUS_ONLINE
4. 当storage server A向tracker server发起心跳，tracker server将其改成FDFS_STORAGE_STATUS_ACTIE

11. FastDFS有哪些优点？

1. 主备Tracker服务，增强系统的可用性
2. 系统不需要支持POSIX，这样的话就降低了系统的复杂度，使得处理的速度会更高
3. 支持主从文件，支持自定义扩展名
4. 支持在线扩容机制，增强了系统的可扩展性
5. 实现了软RAID，增强了系统的并发处理能力和数据容错恢复能力

12. FastDFS有哪些缺点？

1. 通过API下载，存在单点的性能瓶颈
2. 不支持断点续传，对大文件将是噩梦
3. 同步机制不支持文件正确性校验，降低了系统的可用性
4. 不支持POSIX通用接口访问，通用性比较的低
5. 对跨公网的文件同步，存在着比较大的延迟，需要应用做相应的容错策略

13. FastDFS特性有哪些？

Tracker服务器是整个系统的核心枢纽，其完成了访问调度(负载均衡)，监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。

在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。

支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。

14. FastDFS适用的场景以及不适用的场景？

FastDFS是为互联网应用量身定做的一套分布式文件存储系统，非常适合用来存储用户图片、视频、文档等文件。对于互联网应用，和其他分布式文件系统相比，优势非常明显。FastDFS没有对文件做分块存储，因此不太适合分布式计算场景。