1.1. Design concept
FastDFS is a distributed file system tailored for Internet applications. It takes into full consideration redundant backup, load balancing, and linear expansion, and emphasizes high availability and high performance. Compared with the existing Distributed file system like Google FS, FastDFS has its unique architecture and design concept, which is mainly reflected in three aspects: lightweight, grouping and peer structure.
1.2. Lightweight
FastDFS has only two roles: Tracker Server and Storage Server. Tracker Server as the central node, its main function is load balancing and scheduling. The Tracker server records information such as group and Storage server status in the memory. It does not record file index information and occupies a small amount of memory. In addition, when the client (application) and the Storage Server access the Tracker Server, the Tracker Server scans the memory for grouping and Storage Server information and responds. As you can see, Tracker Server is very lightweight and does not become a system bottleneck.
A Storage server in FastDFS is usually referred to as a Trunk Server or Data Server in other file systems. Storage Server directly uses the OS file system to store files. FastDFS does not block files. The files uploaded by the client correspond to the files on the Storage server.
As we all know, most websites need to store files uploaded by users, such as pictures, videos, electronic documents and so on. To reduce bandwidth and storage costs, websites generally limit the size of uploaded files, such as images and videos, to no more than 5MB and 100MB respectively. I don’t think there is much need for file block storage for Internet applications. It neither brings much benefit nor adds complexity to the system. FastDFS does not block files. Compared with DFS that supports file block storage, FastDFS is simpler and more efficient, and can fully meet the practical needs of most Internet applications.
In FastDFS, when a client uploads a file, the file ID is not specified by the client, but generated by the Storage server and returned to the client. The file ID contains the group name, relative file path, and file name. The Storage Server can directly locate the file based on the file ID. So there is no need to store file index information in a FastDFS cluster at all, which is an example of FastDFS being relatively lightweight. Other file systems need to store file index information, and such a role is often called NameServer. MogileFS uses the MySQL database to store file indexes and system-related information. Its limitations are obvious, and MySQL will become the bottleneck of the entire system.
Another aspect of FastDFS ‘lightness is the small amount of code. The latest VERSION of V2.0 includes C client APIS, FastDHT client apis, PHP Extension, and more, with fewer than 52,000 lines of code.
1.3. Grouping method
Google FS supports file redundancy. For example, the backup number of Google FS and TFS is 3. How many storage nodes to store a file is usually allocated dynamically. In this way, the node to which a file is stored is indeterminate. For example, the number of file backups is 3, and the cluster has four storage nodes A, B, C, and D. File 1 May be stored in nodes A, B, and C, file 2 May be stored in nodes B, C, and D, and file 3 May be stored in nodes A, B, and D.
FastDFS uses grouped storage. A cluster consists of one or more groups. The total storage capacity of a cluster is the sum of the storage capacity of all the groups in the cluster. A group consists of one or more Storage servers. The Storage servers in the same group are mutually standby. The files on the Storage servers in the same group are the same. You can upload, download, and delete files on any Storage server in the Storage group. Similar to the short board effect, the storage capacity of a group is the smallest of the storage servers in the group. Therefore, the software and hardware configurations of the storage servers in the group must be consistent.
The advantages of group storage are flexible and controllable. For example, when uploading files, the client can directly specify the group to be uploaded. If storage servers in a group are under heavy access pressure, you can add storage servers to the group to expand service capacity. When the system capacity is insufficient, you can add groups to expand the storage capacity. In this way, you can use FastDFS to manage files and use mainstream Web servers such as Apache and Nginx to download files.
1.4. Peer structure
You can have multiple Tracker servers in a FastDFS cluster, and neither Tracker server nor Storage Server has a single point of view. The relationship between the Tracker servers and the Storage servers in the group is peer. In the traditional master-slave structure, the Master is a single point, and the write operation is only for the Master. If the Master fails, the Slave needs to be promoted to Master. The implementation logic is complicated. Compared with the master-slave structure, the status of all nodes in the peer structure is the same, each node is Master, and there is no single point of problem.
1.5. The architecture diagram
As can be seen from the figure above, the Tracker servers are independent from each other without direct connection.
The client and Storage Server actively connect to the Tracker Server. The Storage Server proactively reports its status information to the Tracker Server, including statistics such as the remaining disk space, file synchronization status, and file upload and download times. The Storage Server connects to all the Tracker servers in the cluster and reports its status to them. The Storage Server starts a separate thread to complete the connection and periodic reporting to a Tracker Server. Note that the Storage server in a group is not specified through the configuration file, but obtained through the Tracker Server.
Storage Servers in different groups do not communicate with each other. Storage Servers in the same group connect to each other for file synchronization.
The Storage server uses binlog files to record update operations, such as uploading and deleting files. Only the file name, not the file content, is recorded in binlog.
File synchronization is implemented only between Storage servers in the same group in push mode, that is, the source server synchronizes files to the target server. Only source data needs to be synchronized. Backup data does not need to be synchronized again. Otherwise, a loop is generated. An exception is that when a new Storage server is added, the existing Storage Server synchronizes all existing data (including source data and backup data) to the new Storage server.
A Storage server synchronizes files based on binlog by a dedicated thread. To minimize interaction and for system simplicity, Storage Server starts a thread for file synchronization on each server in the group except itself.
File synchronization is incremental. The system records the synchronized location (the offset of the binlog file) in an identification file. The id file name format is {dest Storage IP}_{port}. Mark, for example, 192.168.1.14_23000.mark.
