面試：Dubbo&Zookeeper高頻面試題-附加答案

dubbo&zookeeper面試題。

其他推薦：

1. Dubbo中zookeeper做註冊中心，如果註冊中心集羣都掛掉，發佈者和訂閱者之間還能通信麼？

答：可以通信的，啓動dubbo時，消費者會從zk拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用；
註冊中心對等集羣，任意一臺宕機後，將會切換到另一臺；註冊中心全部宕機後，服務的提供者和消費者仍能通過本地緩存通訊。服務提供者無狀態，任一臺宕機後，不影響使用；服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復；
掛掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。

2. dubbo服務負載均衡有哪些策略？

答： l Random LoadBalance
隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。(權重可以在dubbo管控臺配置)

l RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

l LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。使慢的提供者收到更少請求，因爲越慢的提供者的調用前後計數差會越大。

l ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

3. Dubbo在安全機制方面是如何解決的

答： Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。

4. dubbo連接註冊中心和直連的區別

答：在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式，將以服務接口爲單位，忽略註冊中心的提供者列表，服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，註冊中心，服務提供者，服務消費者三者之間均爲長連接，監控中心除外，註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。

5.dubbo通信協議dubbo協議爲什麼要消費者比提供者個數多

答：因dubbo協議採用單一長連接，假設網絡爲千兆網卡(1024Mbit=128MByte)，
根據測試經驗數據每條連接最多隻能壓滿7MByte(不同的環境可能不一樣，供參考)，理論上1個服務提供者需要20個服務消費者才能壓滿網卡。

6.dubbo通信協議dubbo協議爲什麼不能傳大包

答：因dubbo協議採用單一長連接，如果每次請求的數據包大小爲500KByte，假設網絡爲千兆網卡(1024Mbit=128MByte)，每條連接最大7MByte(不同的環境可能不一樣，供參考)，單個服務提供者的TPS(每秒處理事務數)最大爲：128MByte / 500KByte = 262。單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大爲：7MByte / 500KByte = 14。如果能接受，可以考慮使用，否則網絡將成爲瓶頸。

7.dubbo通信協議dubbo協議爲什麼採用異步單一長連接

答：因爲服務的現狀大都是服務提供者少，通常只有幾臺機器，而服務的消費者多，可能整個網站都在訪問該服務，比如Morgan的提供者只有6臺提供者，卻有上百臺消費者，每天有1.5億次調用，如果採用常規的hessian服務，服務提供者很容易就被壓跨，通過單一連接，保證單一消費者不會壓死提供者，長連接，減少連接握手驗證等，並使用異步IO，複用線程池，防止C10K問題。

8.dubbo通信協議dubbo協議適用範圍和適用場景

答： 適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，儘量不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用
dubbo協議補充：

連接個數：單連接
連接方式：長連接
傳輸協議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進制序列化

9. RMI協議

答： RMI協議採用JDK標準的java.rmi.*實現，採用阻塞式短連接和JDK標準序列化方式，Java標準的遠程調用協議。

連接個數：多連接
連接方式：短連接
傳輸協議：TCP
傳輸方式：同步傳輸
序列化：Java標準二進制序列化
適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。
適用場景：常規遠程服務方法調用，與原生RMI服務互操作

10.Thrif

答： Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，比如service name，magic number等。

11.ZooKeeper是什麼？

答： ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，它是集羣的管理者，監視着集羣中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。客戶端的讀請求可以被集羣中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連接的zookeeper機器來處理。對於寫請求，這些請求會同時發給其他 zookeeper 機器並且達成一致後，請求才會返回成功。因此，隨着 zookeeper 的集羣機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱爲 zxid （ Zookeeper Transaction Id ）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個 zookeeper 最新的 zxid 。

12.ZooKeeper提供了什麼？

答： 1、文件系統 2、通知機制

13.Zookeeper文件系統

答： Zookeeper提供一個多層級的節點命名空間（節點稱爲znode）。與文件系統不同的是，這些節點都可以設置關聯的數據，而文件系統中只有文件節點可以存放數據而目錄節點不行。Zookeeper爲了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得Zookeeper 不能用於存放大量的數據，每個節點的存放數據上限爲 1M 。

14. 四種類型的znode

答：
1、 PERSISTENT- 持久化目錄節點客戶端與zookeeper斷開連接後，該節點依舊存在
2、 PERSISTENT_SEQUENTIAL- 持久化順序編號目錄節點
客戶端與zookeeper斷開連接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
3、 EPHEMERAL- 臨時目錄節點
客戶端與zookeeper斷開連接後，該節點被刪除
4、 EPHEMERAL_SEQUENTIAL- 臨時順序編號目錄節點客戶端與zookeeper斷開連接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號。

15.Zookeeper通知機制

答： client端會對某個znode建立一個watcher 事件，當該znode發生變化時，這些client會收到zk的通知，然後client可以根據znode變化來做出業務上的改變等。

16.Zookeeper做了什麼？

答： 1、命名服務 2、配置管理 3、集羣管理 4、分佈式鎖 5、隊列管理

17.zk的命名服務（文件系統）

答：命名服務是指通過指定的名字來 獲取資源 或者 服務的地址 ，利用zk創建一個全局的路徑，即是唯一的路徑，這個路徑就可以作爲一個名字，指向集羣中的集羣，提供的服務的地址，或者一個遠程的對象等等。

18.zk的配置管理（文件系統、通知機制）

答：程序分佈式的部署在不同的機器上，將程序的配置信息放在zk的znode 下，當有配置發生改變時，也就是 znode發生變化時，可以通過改變zk中某個目錄節點的內容，利用 watcher 通知給各個客戶端，從而更改配置。

19.Zookeeper集羣管理（文件系統、通知機制）

答：所謂集羣管理無在乎兩點： 是否有機器退出和加入、選舉 master 。對於第一點，所有機器約定在父目錄下 創建臨時目錄節點 ，然後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對於第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作爲 master 就好。

20.Zookeeper分佈式鎖（文件系統、通知機制）

答：有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。對於第一類，我們將zookeeper上的一個 znode 看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的 distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選 master一樣， 編號最小的獲得鎖 ，用完刪除，依次方便。

21.獲取分佈式鎖的流程

答：在獲取分佈式鎖的時候在locker節點下創建臨時順序節點，釋放鎖的時候刪除該臨時節點。客戶端調用 createNode方法在locker下創建臨時順序節點，然後調用getChildren(“locker”)來獲取locker下面的所有子節點，注意此時不用設置任何Watcher。客戶端獲取到所有的子節點path之後，如果發現自己創建的節點在所有創建的子節點序號最小，那麼就認爲該客戶端獲取到了鎖。如果發現自己創建的節點並非locker所有子節點中最小的，說明自己還沒有獲取到鎖，此時客戶端需要找到 比自己小的那個節點 ，然後對其調用 exist() 方法，同時對其註冊事件監聽器。之後，讓這個被關注的節點刪除，則客戶端的Watcher會收到相應通知，此時再次判斷自己創建的節點是否是locker子節點中序號最小的，如果是則獲取到了鎖，如果不是則重複以上步驟繼續獲取到比自己小的一個節點並註冊監聽。當前這個過程中還需要許多的邏輯判斷。
代碼的實現主要是基於互斥鎖，獲取分佈式鎖的重點邏輯在於BaseDistributedLock ，實現了基於Zookeeper實現分佈式鎖的細節。

22…Zookeeper隊列管理（文件系統、通知機制）

答：兩種類型的隊列： 1、同步隊列，當一個隊列的成員都聚齊時，這個隊列纔可用，否則一直等待所有成員到達。 2、隊列按照 FIFO 方式進行入隊和出隊操作。第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。第二類，和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。
在特定的目錄下創建 PERSISTENT_SEQUENTIAL 節點，創建成功時 Watcher 通知等待的隊列，隊列刪除序列號最小的節點用以消費。此場景下Zookeeper的znode用於消息存儲，znode存儲的數據就是消息隊列中的消息內容， SEQUENTIAL序列號就是消息的編號，按序取出即可。由於創建的節點是持久化的，所以不必擔心隊列消息的丟失問題。

23.Zookeeper數據複製

答： Zookeeper作爲一個集羣提供一致的數據服務，自然，它要在所有機器間做數據複製。數據複製的好處：
1、容錯：一個節點出錯，不致於讓整個系統停止工作，別的節點可以接管它的工作；
2、提高系統的擴展能力：把負載分佈到多個節點上，或者增加節點來提高系統的負載能力；
3、提高性能：讓 客戶端本地訪問就近的節點，提高用戶訪問速度 。
從客戶端讀寫訪問的透明度來看，數據複製集羣系統分下面兩種：
1、寫主 (WriteMaster) ：對數據的修改提交給指定的節點。讀無此限制，可以讀取任何一個節點。這種情況下客戶端需要對讀與寫進行區別，俗稱 讀寫分離 ；
2、寫任意 (Write Any)：對數據的 修改可提交給任意的節點 ，跟讀一樣。這種情況下，客戶端對集羣節點的角色與變化透明。
對zookeeper來說，它採用的方式是寫任意。通過增加機器，它的讀吞吐能力和響應能力擴展性非常好，而寫，隨着機器的增多吞吐能力肯定下降（這也是它建立observer的原因），而響應能力則取決於具體實現方式，是 延遲複製保持最終一致性 ，還是 立即複製快速響應 。

24.Zookeeper工作原理

答： Zookeeper 的核心是 原子廣播 ，這個機制保證了各個 Server 之間的同步。實現這個機制的協議叫做Zab 協議。Zab協議有兩種模式，它們分別是 恢復模式（選主）和廣播模式（同步） 。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。

25.zookeeper是如何保證事務的順序一致性的？

答： zookeeper採用了遞增的事務 Id 來標識，所有的proposal（提議）都在被提出的時候加上了zxid，zxid實際上是一個64位的數字，高32位是epoch（時期; 紀元; 世; 新時代）用來標識leader是否發生改變，如果有新的leader產生出來，epoch會自增， 低 32 位用來遞增計數 。當新產生proposal的時候，會依據數據庫的兩階段過程，首先會向其他的server發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行。

26.Zookeeper 下 Server工作狀態

答：每個Server在工作過程中有三種狀態： LOOKING：當前Server 不知道 leader 是誰，正在搜尋 LEADING：當前Server即爲選舉出來的leader FOLLOWING：leader已經選舉出來，當前Server與之同步。

27.zookeeper是如何選取主leader的？（zookeeper選舉）

答：當leader崩潰或者leader失去大多數的follower，這時zk進入恢復模式，恢復模式需要重新選舉出一個新的 leader，讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基於basic paxos實現的，另外一種是基於fast paxos算法實現的。系統默認的選舉算法爲 fast paxos 。
1、Zookeeper選主流程(basic paxos)
（1）選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的 Server；
（2）選舉線程首先向所有Server發起一次詢問(包括自己)；
（3）選舉線程收到回覆後，驗證是否是自己發起的詢問(驗證zxid是否一致)，然後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(id,zxid)，並將這些信息存儲到當次選舉的投票記錄表中；
（4）收到所有Server回覆以後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server；
（5）線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置自己的狀態，否則，繼續這個過程，直到leader被選舉出來。通過流程分析我們可以得出：要使Leader獲得多數 Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1. 每個Server啓動後都會重複以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復。

2、Zookeeper選主流程(basic paxos)
fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成爲leader，當其它Server收到提議以後，解決epoch和 zxid的衝突，並接受對方的提議，然後向對方發送接受提議完成的消息，重複這個流程，最後一定能選舉出Leader。

28.Zookeeper同步流程

答：選完Leader以後，zk就進入狀態同步過程。
1、Leader等待server連接；
2、Follower連接leader，將最大的zxid發送給leader；
3、Leader根據follower的zxid確定同步點；
4、完成同步後通知follower 已經成爲uptodate狀態；
5、Follower收到uptodate消息後，又可以重新接受client的請求進行服務了。

29.分佈式通知和協調

答：對於系統調度來說：操作人員發送通知實際是通過控制檯 改變某個節點的狀態 ，然後 zk 將這些變化發送給註冊了這個節點的 watcher 的所有客戶端 。對於執行情況彙報：每個工作進程都在某個目錄下 創建一個臨時節點 。並攜帶工作的進度數據，這樣 彙總的進程可以監控目錄子節點的變化獲得工作進度的實時的全局情況 。

30.機器中爲什麼會有leader？

答：在分佈式環境中，有些業務邏輯只需要集羣中的某一臺機器進行執行， 其他的機器可以共享這個結果 ，這樣可以大大 減少重複計算，提高性能 ，於是就需要進行leader選舉。

31.zk節點宕機如何處理？

答： Zookeeper本身也是集羣，推薦配置不少於3個服務器。Zookeeper自身也要保證當一個節點宕機時，其他節點會繼續提供服務。如果是一個Follower宕機，還有2臺服務器提供訪問，因爲Zookeeper上的數據是有多個副本的，數據並不會丟失；如果是一個Leader宕機，Zookeeper會選舉出新的Leader。 ZK集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在ZK節點掛得太多，只剩一半或不到一半節點能工作，集羣才失效。所以 3個節點的cluster可以掛掉1個節點(leader可以得到2票>1.5) 2個節點的cluster就不能掛掉任何1個節點了(leader可以得到1票<=1) 。

32.zookeeper負載均衡和nginx負載均衡區別

答： zk的負載均衡是可以調控，nginx只是能調權重，其他需要可控的都需要自己寫插件；但是nginx的吞吐量比 zk大很多，應該說按業務選擇用哪種方式。

33.zookeeper watch機制

答： Watch機制官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們。 Zookeeper機制的特點：
1、一次性觸發數據發生改變時，一個watcher event會被髮送到client，但是client
只會收到一次這樣的信息。
2、watcher event異步發送watcher的通知事件從server發送到client是異步的，這就存在一個問題，不同的客戶端和服務器之間通過socket進行通信，由於 網絡延遲或其他因素導致客戶端在不通的時刻監聽到事件 ，由於Zookeeper本身提供了 ordering guarantee ，即客戶端監聽事件後，纔會感知它所監視 znode 發生了變化 。所以我們使用Zookeeper不能期望能夠監控到節點每次的變化。Zookeeper 只能保證最終的一致性，而無法保證強一致性。
3、數據監視Zookeeper有數據監視和子數據監視getdata() and exists()設置數據監視，getchildren()設置了子節點監視。
4、註冊watcher getData 、 exists 、 getChildren。
5、觸發watcher create 、 delete 、 setData。
6、 setData() 會觸發znode上設置的data watch（如果set成功的話）。一個成功的 create() 操作會觸發被創建的znode上的數據watch，以及其父節點上的child watch。而一個成功的 delete() 操作將會同時觸發一個znode的data watch和child watch（因爲這樣就沒有子節點了），同時也會觸發其父節點的child watch。
7、當一個客戶端 連接到一個新的服務器上時，watch將會被以任意會話事件觸發。當與一個服務器失去連接的時候，是無法接收到watch的。而當client 重新連接時，如果需要的話，所有先前註冊過的watch，都會被重新註冊。通常這是完全透明的。只有在一個特殊情況下， watch 可能會丟失 ：對於一個未創建的znode的 exist watch，如果在客戶端斷開連接期間被創建了，並且隨後在客戶端連接上之前又刪除了，這種情況下，這個watch事件可能會被丟失。
8、Watch是輕量級的，其實就是本地JVM的 Callback ，服務器端只是存了是否有設置了Watcher的布爾類型。

33.Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

dubbo：單一長連接和 NIO 異步通訊，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步，Hessian 序列化。
rmi：採用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象需要實現 Serializable 接口，使用 java 標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議 TCP。多個短連接，TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞。
webservice：基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操作。多個短連接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用。
http：基於 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短連接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，需要給應用程序和瀏覽器 JS 調。
hessian：集成 Hessian 服務，基於 HTTP 通訊，採用 Servlet 暴露服務， Dubbo 內嵌 Jetty 作爲服務器時默認實現，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件。
memcache：基於 memcached 實現的 RPC 協議。
redis：基於 redis 實現的 RPC 協議。

34.Dubbo 超時時間怎樣設置？

答：　Dubbo 超時時間設置有兩種方式：

服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦如果能在服務端多配置就儘量多配置，因爲服務提供者比消費者更清楚自己提供的服務特性。
服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端爲主，即優先級更高。因爲服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定製，會產生警告。

35.Dubbo 有些哪些註冊中心？

Multicast 註冊中心： Multicast 註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；
Zookeeper 註冊中心：基於分佈式協調系統 Zookeeper 實現，採用 Zookeeper 的 watch 機制實現數據變更；
redis 註冊中心：基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過期時間。基於 redis 的發布/訂閱模式通知數據變更；
Simple 註冊中心

36.Dubbo 集羣的負載均衡有哪些策略

答： Dubbo 提供了常見的集羣策略實現，並預擴展點予以自行實現。

Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；
RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，但是存在請求累積的問題；
LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；
ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動

37.Dubbo是什麼？

答： Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案，可以和Spring框架無縫集成。

38.Dubbo的主要應用場景？

透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，
只需簡單配置，沒有任何API侵入。
軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，
降低成本，減少單點。
服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心
基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪
除服務提供者。

39.Dubbo的核心功能？

Remoting：網絡通信框架，提供對多種NIO框架抽象封裝，包括
“同步轉異步”和“請求-響應”模式的信息交換方式。
**Cluster：服務框架，**提供基於接口方法的透明遠程過程調用，包括多
協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣
支持。
Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態
的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少
機器。

40.Dubbo的核心組件？

41.Dubbo服務註冊與發現的流程？

Provider(提供者)綁定指定端口並啓動服務
指供者連接註冊中心，併發本機IP、端口、應用信息和提供服務信息
發送至註冊中心存儲
Consumer(消費者），連接註冊中心，併發送應用信息、所求服務信
息至註冊中心
註冊中心根據消費者所求服務信息匹配對應的提供者列表發送至
Consumer 應用緩存。
Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調
用。
Provider 狀態變更會實時通知註冊中心、在由註冊中心實時推送至
Consumer

42.Dubbo的架構設計？

答： Dubbo框架設計一共劃分瞭如下幾層：

服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提
供方和服務消費方的業務設計對應的接口和實現
配置層（Config）：對外配置接口，以ServiceConfig和
ReferenceConfig爲中心。
服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub
和服務器端Skeleton。
服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL
爲中心。
集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊
中心，以Invoker爲中心。
監控層（Monitor）：RPC調用次數和調用時間監控。
遠程調用層（Protocol）：封將RPC調用，以Invocation和Result
爲中心，擴展接口爲Protocol、Invoker和Exporter。
信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以
Request和Response爲中心。
網絡傳輸層（Transport）：抽象mina和netty爲統一接口，以
Message爲中心。

43.dubbo推薦用什麼協議？

默認使用dubbo協議

44.爲什麼需要服務治理？

過多的服務URL配置困難
負載均衡分配節點壓力過大的情況下也需要部署集羣
服務依賴混亂，啓動順序不清晰
過多服務導致性能指標分析難度較大，需要監控

45. Dubbo與Spring的關係？

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。

46.Dubbo使用的是什麼通信框架?

默認使用NIO Netty框架。

47.Dubbo的集羣容錯方案有哪些？

Failover Cluster ：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但
重試會帶來更長延遲。
Failfast Cluster ：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster ：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
Failback Cluster ：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
Forking Cluster：並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較
高的讀操作，但需要浪費更多服務資源。可通過 forks=“2” 來設置最大並行數。
Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。通常用於通知所有提供者更新緩存或日誌等本地資源信息。

48.Dubbo的默認集羣容錯方案？

Failover Cluster

49.Dubbo支持哪些序列化方式？

默認使用Hessian序列化，還有Duddo、FastJson、Java自帶序列
化。

50.Dubbo超時時間怎樣設置？

服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就儘量多配置，因爲服務提供者比消費者更清楚自己提供的服務特性。
服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端爲主，即優先級更高。因爲服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定製，會產生警告。

51.服務調用超時問題怎麼解決？

dubbo在調用服務不成功時，默認是會重試兩次的。

52.Dubbo在安全機制方面是如何解決？

Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。

53.Dubbo 和 Dubbox 之間的區別？

dubbox 基於 dubbo 上做了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

54.Dubbo和Spring Cloud的關係？

Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外由於依託了 Spirng、Spirng Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

55.Dubbo和Spring Cloud的區別？

最大的區別：Dubbo底層是使用Netty這樣的NIO框架，是基於TCP協議傳輸的，配合以Hession序列化完成RPC通信。
而SpringCloud是基於Http協議+Rest接口調用遠程過程的通信，相對來說，Http請求會有更大的報文，佔的帶寬也會更多。但是REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。