1、rebbitmq的使用場景有哪些？

(1)單發送單接受

使用場景：簡單的發送與接受，沒有特別的處理。

(2)單發送多接受

使用場景：一個發送端，多個接收端，如分布式的任務發布，要保證消息發送的可靠性，不丟失消息，所以將消息隊列持久化，同時為了防止接收端處理消息時宕機，所以在處理完成后再發送ack滿息。

(3)Publish/Subscribe

使用場景：發布、訂閱模式，發送端發送廣播消息，多個接收端接受。

(4)Routing(按路線發送接收)

使用場景：發送端按routing key發送滿息，不同的接收端按不同的routing key接收消息。

(5)Topics(按Topic發送接收)

使用場景：發送端不只按routing key發送消息，而是按字符串“匹配”發送，接收端同樣如此。

2、Dubbo的容錯機制有哪些？

(1)Failover Cluster模式

失敗自動切換，當出現失敗，重試其它服務器。(默認)

(2)Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

(3)Failsafe Cluster

失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。

(4)Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發。通常用于消息通知操作。

(5)Forking Cluster

并行調用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過forks=”2”來設置最大并行數。

(6)Broadcast Cluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)通常用于通知所有提供者更新緩存或日志等本地資源信息。

總結：

在實際應用中查詢語句容錯策略建議使用默認Failover Cluster，而增刪改建議使用Failfast Cluster或者使用Failover Cluster(retries=”0”)策略防止出現數據重復添加等等其它問題！建議在設計接口時候把查詢接口方法單獨做一個接口提供查詢。

3、Dubbo和Spring Cloud 有什么區別？

(1)通信方式不同

Dubbo使用的是RPC通信，而Spring Cloud使用的是HTTPRESTFul方式。

(2)組成部分不同

4、Dubbo 里面有哪幾種節點角色？

(1)Provider

暴露服務的服務提供方。

(2)Consumer

調用遠程服務的服務消費方。

(3)Registry

服務注冊與發現的注冊中心。

(4)Monitor

統計服務的調用次數和調用時間的監控中心。

(5)Container

服務運行容器。

5、Dubbo服務注冊與發現的流程圖

6、Dubbo 有幾種負載均衡策略，默認是哪種？

(1)Random LoadBalance

隨機，按權重設置隨機概率(默認)。

(2)RoundRobin LoadBalance

輪詢，按公約后的權重設置輪詢比率。

(3)LeastActive LoadBalance

最少活躍調用數，相同活躍數的隨機。

(4)ConsistentHash LoadBalance

一致性Hash，相同參數的請求總是發到同一提供者。

7、ZooKeeper 是什么？

ZooKeeper是一個開放源碼的分布式協調服務，它是集群的管理者，監視著集群中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

分布式應用程序可以基于Zookeeper實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master選舉、分布式鎖和分布式隊列等功能。

Zookeeper保證了如下分布式一致性特性：

(1)順序一致性

(2)原子性

(3)單一視圖

(4)可靠性

(5)實時性(最終一致性)

客戶端的讀請求可以被集群中的任意一臺機器處理，如果讀請求在節點上注冊了監聽器，這個監聽器也是由所連接的zookeeper機器來處理。對于寫請求，這些請求會同時發給其他zookeeper機器并且達成一致后，請求才會返回成功。因此，隨著zookeeper的集群機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。

有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為zxid(Zookeeper TransactionId)。而讀請求只會相對于更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。

8、Zookeeper Watcher 機制-數據變更通知

Zookeeper 允許客戶端向服務端的某個Znode注冊一個Watcher監聽，當服務端的一些指定事件觸發了這個Watcher，服務端會向指定客戶端發送一個事件通知來實現分布式的通知功能，然后客戶端根據Watcher通知狀態和事件類型做出業務上的改變。

工作機制：

(1)客戶端注冊 watcher

(2)服務端處理watcher

(3)客戶端回調 watcher

Watcher特性總結：

(1)一次性

無論是服務端還是客戶端，一旦一個Watcher被觸發，Zookeeper都會將其從相應的存儲中移除。這樣的設計有效的減輕了服務端的壓力，不然對于更新非常頻繁的節點，服務端會不斷的向客戶端發送事件通知，無論對于網絡還是服務端的壓力都非常大。

(2)客戶端串行執行

客戶端Watcher回調的過程是一個串行同步的過程。

(3)輕量

Watcher通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。

客戶端向服務端注冊 Watcher的時候，并不會把客戶端真實的Watcher對象實體傳遞到服務端，僅僅是在客戶端請求中使用boolean類型屬性進行了標記。

watcher event 異步發送watcher的通知事件從server發送到client是異步的，這就存在一個問題，不同的客戶端和服務器之間通過socket進行通信，由于網絡延遲或其他因素導致客戶端在不通的時刻監聽到事件，由于Zookeeper本身提供了ordering guarantee，即客戶端監聽事件后，才會感知它所監視znode發生了變化。所以我們使用Zookeeper不能期望能夠監控到節點每次的變化。

Zookeeper只能保證最終的一致性，而無法保證強一致性。

注冊 watcher getData、exists、getChildren

觸發watcher create、delete、setData

當一個客戶端連接到一個新的服務器上時，watch將會被以任意會話事件觸發。當與一個服務器失去連接的時候，是無法接收到watch的。而當client重新連接時，如果需要的話，所有先前注冊過的watch，都會被重新注冊。通常這是完全透明的。只有在一個特殊情況下，watch可能會丟失：對于一個未創建的znode的exist watch，如果在客戶端斷開連接期間被創建了，并且隨后在客戶端連接上之前又刪除了，這種情況下，這個watch事件可能會被丟失。

9、Zookeeper四種類型的數據節點Znode

(1)PERSISTENT-持久節點

除非手動刪除，否則節點一直存在于Zookeeper上。

(2)EPHEMERAL-臨時節點

臨時節點的生命周期與客戶端會話綁定，一旦客戶端會話失效(客戶端與zookeeper連接斷開不一定會話失效)，那么這個客戶端創建的所有臨時節點都會被移除。

(3)PERSISTENT_SEOUENTIAL-持久順序節點

基本特性同持久節點，只是增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字。

(4)EPHEMERAL_SEQUENTIAL-臨時順序節點

基本特性同臨時節點，增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字。

10、Zookeeper選舉算法及流程

假設有5臺服務器，每臺服務器均沒有數據，它們的編號分別是1，2，3，4，5，按編號依次啟動，它們的選擇舉過程如下：

(1)服務器1啟動，給自己投票，然后發投票信息，由于其它機器還沒有啟動所以它收不到反饋信息，服務器1的狀態一直屬于Looking(選舉狀態)。

(2)服務器2啟動，給自己投票，同時與之前啟動的服務器1交換結果，由于服務器2的編號大所以服務器2勝出，但此時投票數沒有大于半數，所以兩個服務器的狀態依然是LOOKING。

(3)服務器3啟動，給自己投票，同時與之前啟動的服務器1，2交換信息，由于服務器3的編號最大所以服務器3勝出，此時投票數正好大于半數，所以服務器3成為領導者，服務器1.2成為小弟。

(4)服務器4啟動，給自己投票，同時與之前啟動的服務器1，2，3交換信息，盡管服務器4的編號大，但之前服務器3已經勝出，所以服務器4只能成為小弟。

(5)服務器5啟動，后面的邏輯同服務器4成為小弟。

11、集群中的機器角色都有哪些？

(1)Leader

事務請求的唯一調度和處理者，保證集群事務處理的順序性，集群內部各服務的調度者。

(2)Follower

處理客戶端的非事務請求，轉發事務請求給Leader服務器參與事務請求Proposal的投票。參與Leader選舉投票。

(3)Observer

3.3.0版本以后引入的一個服務器角色，在不影響集群事務處理能力的基礎上提升集群的非事務處理能力處理客戶端的非事務請求，轉發事務請求給Leader服務器，不參與任何形式的投票。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的java把收集的数据节点_java面试题收集(04)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。