FastDFS

principle

Tracker server:

The function is load balancing and scheduling. When uploading files, the Tracker server can find the Storage server according to some policies to provide file upload services. A Tracker can be called a tracking server or a scheduling server. The information that the Tracker needs to manage is also stored in memory, and all trackers in it are peer-to-peer (the status of each node is equal), which is easy to expand.

Storage server:

The function is file storage. The files uploaded by the client are finally stored on the storage server. The Storageserver does not implement its own file system, but uses the file system of the operating system to manage files. Storage can be called a storage server; It is actually used to save files. Storage is divided into multiple groups, and the files saved between each group are different. Each group can have multiple members. The contents saved in the group members are the same. The status of group members is the same, and there is no concept of master-slave. That is, upload a file to one of the storage, and other storage in the same group will synchronize the files.

For data synchronization of Storage, use binlog:

1. The Storage Server starts a thread for each Tracker in the file system
   1) Used to communicate with Tracker.
   2) Implement the heartbeat feedback mechanism. By default, heartbeat packets are sent to the Tracker every 30 seconds, including other Storage information in the same group.
   3) This thread obtains the Storage list information from the Tracker
2. Storage opens a thread for each storage in the same group
   1) Obtain the information of other storage servers in the same group from the tracker, and synchronize data to these storage servers according to binlog (blocking mode).
   2) If there are three Storage in the group, each Storage starts two threads to synchronize data to other Storage.
   3) Open the mark file of / data/sync and read the target Storage_Server_IP.mark file to obtain the corresponding binlog file and synchronized offset.
   4) Find the file operation corresponding to offset in the corresponding binlog file. If this operation is a source operation (CADT), synchronize the operation to the outside. Update the offset value of the mark file after synchronization

to configure

The configuration contents are as follows:

# storage.conf
group_name = group1

tracker_server = localServer:22122
tracker_server = peerServer1:22122
tracker_server = peerServer2:22122
...

# tracker.conf
store_group = group1

test

The test configuration is as follows:

# 237
## /etc/hosts
10.10.10.237 localServer
10.10.10.238 peerServer
10.10.10.104 server104
## tracker.conf
store_group = group1
## storage.conf
group_name = group1
tracker_server = localServer:22122
tracker_server = peerServer:22122
tracker_server = server104:22122

# 238
## /etc/hosts
10.10.10.238 localServer
10.10.10.237 peerServer
10.10.10.104 server104
## tracker.conf
store_group = group1
## storage.conf
group_name = group1
tracker_server = localServer:22122
tracker_server = peerServer:22122
tracker_server = server104:22122

# 104
## /etc/hosts
10.10.10.104 localServer
10.10.10.237 server237
10.10.10.238 server238
## tracker.conf
store_group = group1
## storage.conf
group_name = group1
tracker_server = localServer:22122
tracker_server = server237:22122
tracker_server = server238:22122

Use the client provided with fdfs to upload, download and delete files. The commands are as follows:

# upload
/usr/bin/fdfs_upload_file /etc/fdfs/client.conf filePath
# download
/usr/bin/fdfs_download_file /etc/fdfs/client.conf fileId
# delete
/usr/bin/fdfs_delete_file /etc/fdfs/client.conf fileId 

Upload the file test from 237, then close the storage of 237, download the file, and the download is successful;

Continue to close the storage of 238, download the file, and the download is successful;

Continue to close the storage of 104 and download the file. The download failed. This indicates that the file has been synchronized to each storage.

Restart all storage, delete the file, download the file, and the download fails; Close 237, 238 and 104 respectively for download test, and the download failed. This indicates that the file has been deleted by each storage.

Because FastDFS does not have the concept of active and standby, all storage in the same group will synchronize data with each other. Therefore, there is no need to carry out special processing on FastDFS through code. It is only necessary to configure multiple correct tracker s and correct groups during initial configuration.