Java全栈面试题汇总目录
https://blog.csdn.net/weixin_42173947/article/details/138966376
目录
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的交互过程是怎样的？
- client询问tracker上传到的storage，不需要附加参数
- tracker返回一台可用的storage
- 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时，由系统自动完成已有数据同步，处理逻辑如下
- 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，进入第二步的处理
- 假设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的同步由追加同步改成正常同步,只同步源头数据
- storage server B向storage server A同步完所有数据，暂没有数据同步时，storage server B请求tracker server将storage server状态设置为FDFS_STORAGE_STATUS_ONLINE
- 当storage server A向tracker server发起心跳，tracker server将其改成FDFS_STORAGE_STATUS_ACTIE
11 FastDFS有哪些优点？
- 主备Tracker服务，增强系统的可用性
- 系统不需要支持POSIX，这样的话就降低了系统的复杂度，使得处理的速度会更高
- 支持主从文件，支持自定义扩展名
- 支持在线扩容机制，增强了系统的可扩展性
- 实现了软RAID，增强了系统的并发处理能力和数据容错恢复能力
12 FastDFS有哪些缺点？
- 通过API下载，存在单点的性能瓶颈
- 不支持断点续传，对大文件将是噩梦
- 同步机制不支持文件正确性校验，降低了系统的可用性
- 不支持POSIX通用接口访问，通用性比较的低
- 对跨公网的文件同步，存在着比较大的延迟，需要应用做相应的容错策略
13 FastDFS特性有哪些？
Tracker服务器是整个系统的核心枢纽，其完成了访问调度(负载均衡)，监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。
在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。
14 FastDFS适用的场景以及不适用的场景？
FastDFS是为互联网应用量身定做的一套分布式文件存储系统，非常适合用来存储用户图片、视频、文档等文件。对于互联网应用，和其他分布式文件系统相比，优势非常明显。FastDFS没有对文件做分块存储，因此不太适合分布式计算场景。
8578
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
