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沒有對文件做分塊存儲，因此不太適合分布式計算場景。