目錄
@、fastDFS分佈式文件系統
fastDFS有兩個角色：跟蹤器（tracker）和存儲節點（storage）；
存儲數據：
跟蹤器負責記錄圖片地址，和響應java接口訪問。java接口要想儲存圖片地址需向跟蹤器發送請求，然後由跟蹤器查找圖片倉庫地址發給java接口，同時記錄儲存過程，
Java接口配IP是配2個的，因爲有2個跟蹤器，而java接口連接IP時並不是智能的，如果連接第一個跟蹤器沒反應（第一個沒反應不是忙就是掛了），它就會連接第二個跟蹤器，不管連哪個跟蹤器，最終都會返回一個地址給java接口。而兩個跟蹤器之間是有通信的，它們會把信息同步的，這個信息也就是meta信息，也就是管理的帳本。
跟蹤器和存儲節點有通信間隔時間，這個時間由我們決定。而存儲節點之間也是有通信的，如果有一天存儲節點和存儲節點的倉庫都滿了，就擴張倉庫，創建下一組存儲節點和存儲倉庫。
取數據：
取數據的時候可以用java接口取，也可以用頁面裏的<img src=”http//…..jpg/>”取，但是src屬性會在頁面加載後發出2次請求。Src會根據地址去找跟蹤器，而跟蹤器會告訴它這地址圖片在哪個存儲節點身上，跟蹤器這臺機器上搭建是nginx服務器（反向代理服務器）這個服務器是用來解決高併發用的。Nginx服務器會根據你的路徑找到存儲節點身上的圖片。然後再將存儲節點的圖片拿回來，再加載給src,到img標籤裏。
啓動：
先設置IP再修改IP，然後三個命令分別啓動跟蹤器，存儲節點，Nginx服務器。
@、談下你對 Zookeeper 的認識？
ZooKeeper 是一個分佈式的，開放源碼的分佈式應用程序協調服務。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
@、Zookeeper 都有哪些功能？
1. 集羣管理：監控節點存活狀態、運行請求等；
2. 主節點選舉：主節點掛掉了之後可以從備用的節點開始新一輪選主，主節點選舉說的就是這個選舉的過程，使用 Zookeeper 可以協助完成這個過程；
3. 分佈式鎖：Zookeeper 提供兩種鎖：獨佔鎖、共享鎖。獨佔鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，即可以有多線線程同時讀同一個資源，如果要使用寫鎖也只能有一個線程使用。Zookeeper 可以對分佈式鎖進行控制。
4. 命名服務：在分佈式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。
@、談下你對 ZAB 協議的瞭解？
ZAB 協議是爲分佈式協調服務 Zookeeper 專門設計的一種支持崩潰恢復的原子廣播協議。ZAB 協議包括兩種基本的模式：崩潰恢復和消息廣播。
當整個 Zookeeper 集羣剛剛啓動或者Leader服務器宕機、重啓或者網絡故障導致不存在過半的服務器與 Leader 服務器保持正常通信時，所有服務器進入崩潰恢復模式，首先選舉產生新的 Leader 服務器，然後集羣中 Follower 服務器開始與新的 Leader 服務器進行數據同步。當集羣中超過半數機器與該 Leader 服務器完成數據同步之後，退出恢復模式進入消息廣播模式，Leader 服務器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。
@、Zookeeper 怎麼保證主從節點的狀態同步？
Zookeeper 的核心是原子廣播機制，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫做 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。
1. 恢復模式
當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數 server 完成了和 leader 的狀態同步以後，恢復模式就結束了。狀態同步保證了 leader 和 server 具有相同的系統狀態。
2. 廣播模式
一旦 leader 已經和多數的 follower 進行了狀態同步後，它就可以開始廣播消息了，即進入廣播狀態。這時候當一個 server 加入 ZooKeeper 服務中，它會在恢復模式下啓動，發現 leader，並和 leader 進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper 服務一直維持在 Broadcast 狀態，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持。
Zookeeper 有幾種部署模式？
Zookeeper 有三種部署模式：
1. 單機部署：一臺集羣上運行；
2. 集羣部署：多臺集羣運行；
3. 僞集羣部署：一臺集羣啓動多個 Zookeeper 實例運行。
@、說一下 Zookeeper 的通知機制？
client 端會對某個 znode 建立一個 watcher 事件，當該 znode 發生變化時，這些 client 會收到 zk 的通知，然後 client 可以根據 znode 變化來做出業務上的改變等。
@、集羣中爲什麼要有主節點？
在分佈式環境中，有些業務邏輯只需要集羣中的某一臺機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重複計算，提高性能，於是就需要進行 leader 選舉。
集羣中有 3 臺服務器，其中一個節點宕機，這個時候 Zookeeper 還可以使用嗎？
可以繼續使用，單數服務器只要沒超過一半的服務器宕機就可以繼續使用。
集羣規則爲 2N+1 臺，N >0，即最少需要 3 臺。
@、說一下兩階段提交和三階段提交的過程？分別有什麼問題？
兩階段提交協議 2PC
1. 第一階段（投票階段）：
（1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應；
（2）參與者節點執行詢問發起爲止的所有事務操作，並將Undo信息和Redo信息寫入日誌。
（3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”消息。
2. 第二階段（提交執行階段）：
當協調者節點從所有參與者節點獲得的相應消息都爲”同意”時：
（1）協調者節點向所有參與者節點發出”正式提交(commit)”的請求；
（2）參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源；
（3）參與者節點向協調者節點發送”完成”消息；
（4）協調者節點受到所有參與者節點反饋的”完成”消息後，完成事務。
兩階段提交存在的問題：
1. 執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態；
2. 參與者發生故障：協調者需要給每個參與者額外指定超時機制，超時後整個事務失敗；
3. 協調者發生故障：參與者會一直阻塞下去。需要額外的備機進行容錯；
4. 二階段無法解決的問題：協調者再發出 commit 消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
三階段提交協議 3PC
與兩階段提交不同的是，三階段提交有兩個改動點：
1. 引入超時機制。同時在協調者和參與者中都引入超時機制；
2. 在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。
也就是說，除了引入超時機制之外，3PC 把 2PC 的準備階段再次一分爲二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。
1. CanCommit 階段
3PC 的 CanCommit 階段其實和 2PC 的準備階段很像。協調者向參與者發送 commit 請求，參與者如果可以提交就返回 Yes 響應，否則返回 No 響應。
（1）事務詢問：協調者向參與者發送 CanCommit 請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
（2）響應反饋：參與者接到 CanCommit 請求之後，正常情況下，如果其自身認爲可以順利執行事務，則返回 Yes 響應，並進入預備狀態。否則反饋 No。
2. PreCommit 階段
協調者根據參與者的反應情況來決定是否可以繼續事務的 PreCommit 操作。根據響應情況，有以下兩種可能：
假如協調者從所有的參與者獲得的反饋都是 Yes 響應，那麼就會執行事務的預執行。
（1）發送預提交請求：協調者向參與者發送 PreCommit 請求，並進入 Prepared 階段。
（2）事務預提交：參與者接收到 PreCommit 請求後，會執行事務操作，並將 undo 和 redo 信息記錄到事務日誌中。
（3）響應反饋：如果參與者成功的執行了事務操作，則返回 ACK 響應，同時開始等待最終指令。
假如有任何一個參與者向協調者發送了 No 響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。
（1）發送中斷請求：協調者向所有參與者發送 abort 請求。
（2）中斷事務：參與者收到來自協調者的 abort 請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。
3. doCommit 階段
該階段進行真正的事務提交，也可以分爲以下兩種情況。
3.1 執行提交
（1）發送提交請求：協調接收到參與者發送的 ACK 響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者發送 doCommit 請求。
（2）事務提交：參與者接收到 doCommit 請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
（3）響應反饋：事務提交完之後，向協調者發送 ACK 響應。
（4）完成事務：協調者接收到所有參與者的 ACK 響應之後，完成事務。
3.2 中斷事務
協調者沒有接收到參與者發送的 ACK 響應（可能是接受者發送的不是 ACK 響應，也可能響應超時），那麼就會執行中斷事務。
（1）發送中斷請求：協調者向所有參與者發送 abort 請求。
（2）事務回滾：參與者接收到 abort 請求之後，利用其在階段二記錄的 undo 信息來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
（3）反饋結果：參與者完成事務回滾之後，向協調者發送 ACK 消息。
（4）中斷事務：協調者接收到參與者反饋的 ACK 消息之後，執行事務的中斷。
三階段提交的問題：
網絡分區可能會帶來問題。需要四階段解決：四階段直接調用遠程服務的數據狀態，確定當前數據一致性的情況。
@、Zookeeper 宕機如何處理？
Zookeeper 本身也是集羣，推薦配置不少於 3 個服務器。Zookeeper 自身也要保證當一個節點宕機時，其他節點會繼續提供服務。如果是一個 Follower 宕機，還有 2 臺服務器提供訪問，因爲 Zookeeper 上的數據是有多個副本的，數據並不會丟失；如果是一個 Leader 宕機，Zookeeper 會選舉出新的 Leader。
Zookeeper 集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在 Zookeeper 節點掛得太多，只剩一半或不到一半節點能工作，集羣才失效。所以：
3 個節點的 cluster 可以掛掉 1 個節點(leader 可以得到 2 票 > 1.5)
2 個節點的 cluster 就不能掛掉任何1個節點了(leader 可以得到 1 票 <= 1)
@、 說下四種類型的數據節點 Znode？
1. PERSISTENT：持久節點，除非手動刪除，否則節點一直存在於 Zookeeper 上。
2. EPHEMERAL：臨時節點，臨時節點的生命週期與客戶端會話綁定，一旦客戶端會話失效（客戶端與 Zookeeper連接斷開不一定會話失效），那麼這個客戶端創建的所有臨時節點都會被移除。
3. PERSISTENT_SEQUENTIAL：持久順序節點，基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
4. EPHEMERAL_SEQUENTIAL：臨時順序節點，基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
@、Zookeeper 和 Dubbo 的關係？
Dubbo 的將註冊中心進行抽象，是得它可以外接不同的存儲媒介給註冊中心提供服務，有 ZooKeeper，Memcached，Redis 等。
引入了 ZooKeeper 作爲存儲媒介，也就把 ZooKeeper 的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時 候就需要分流，負載均衡就是爲了分流而存在的，一個 ZooKeeper 羣配合相應的 Web 應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不 夠，節點之間的數據和資源需要同步，ZooKeeper 集羣就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啓動 的時候，向 ZooKeeper 上的指定節點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址，這個操作就完成了服務的發佈。 其他特性還有 Mast 選舉，分佈式鎖等。
Java面試題-fastDFS
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.