dubbo跟thrift都是比較常見的RPC框架。

Dubbo

Dubbo只支持Java語言。

Dubbo 的架構主要包含四個角色，其中 Consumer 是服務消費者，Provider 是服務提供者，Registry 是注冊中心，Monitor 是監控系統。具體的交互流程是 Consumer 一端通過注冊中心獲取到 Provider 節點后，通過 Dubbo 的客戶端 SDK 與 Provider 建立連接，并發起調用。Provider 一端通過 Dubbo 的服務端 SDK 接收到 Consumer 的請求，處理后再把結果返回給 Consumer。

• From：hongda整理的面試題

分布式方面的問題收集

1.Dubbo簡介：

調用關系：

服務容器負責啟動，加載，運行服務提供者。
服務提供者在啟動時，向注冊中心注冊自己提供的服務。
服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

http://dubbo.io/books/dubbo-user-book/preface/architecture.html

2.Dubbo中zookeeper做注冊中心，如果注冊中心集群都掛掉，發布者和訂閱者之間還能通信么？

可以的，啟動dubbo時，消費者會從zk拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用
注冊中心對等集群，任意一臺宕掉后，會自動切換到另一臺
注冊中心全部宕掉，服務提供者和消費者仍可以通過本地緩存通訊
服務提供者無狀態，任一臺宕機后，不影響使用
服務提供者全部宕機，服務消費者會無法使用，并無限次重連等待服務者恢復

3 dubbo連接注冊中心和直連的區別

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

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

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

5.dubbo默認使用什么序列化框架

默認使用Hessian,現在高效的有Kryo和FST

6.Dubbo超時設置和重連機制:

DUBBO消費端設置超時時間需要根據業務實際情況來設定，如果設置的時間太短，一些復雜業務需要很長時間完成，導致在設定的超時時間內無法完成正常的業務處理。

這樣消費端達到超時時間，那么dubbo會進行重試機制，不合理的重試在一些特殊的業務場景下可能會引發很多問題，需要合理設置接口超時時間。

dubbo在調用服務不成功時，默認會重試2次。Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質量。

但是如果不合理的配置重試次數，當失敗時會進行重試多次，這樣在某個時間點出現性能問題，調用方再連續重復調用，系統請求變為正常值的retries倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。

在重試發送的時候也可能會出現這樣的問題:
比如有一個bug反饋,但是因為數據庫io瓶頸,這時候這個服務阻塞了,然后過了一會查看數據庫里有3條除了id外剩下都一樣的數據(id是在服務提供者里生成的,這里只做異常例子舉例).

這就是重試機制下,業務不合理的設計所造成的坑,這時候我們處理的方式有兩種:

合理規劃業務(例如id放在服務上游生成,數據庫主鍵唯一的機制)
服務增加冪等性設置(例如接口中增加消息id)

7.Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多種協議，但是Dubbo官網是推薦我們使用Dubbo協議的。

dubbo協議：

缺省協議，使用基于mina1.1.7 NIO框架庫+hessian3.2.1 序列化協議 的tbremoting交互。
連接個數：單連接
連接方式：長連接
傳輸協議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進制序列化
適用范圍：傳入傳出參數數據包較小（建議小于100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用

http://blog.csdn.net/fuyuwei2015/article/details/72848310

https://www.cnblogs.com/1201x/p/6482638.html

8.為什么要消費者比提供者個數多：

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

9.為什么不能傳大包：

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

10.為什么采用異步單一長連接：

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

網絡服務在處理數以萬計的客戶端連接時，往往出現效率底下甚至完全癱瘓，這被成為C10K問題。
(C10K = connection 10 kilo 問題)。k 表示 kilo，即 1000 比如：kilometer(千米), kilogram(千克)。
linux方面使用epoll解決方案

11.Java Remoting選取方案

性能要求特別高的：可以選用Socket，RMI；
跨平臺，跨語言，安全性，易用性：Webservice；
跨平臺，跨語言，易用性，性能：Hessian，REST；
不跨語言，性能，易用性：NIO(Netty，Mina)，RMI。

12.Dubbo負載均衡和集群容錯模式：

在集群負載均衡時，Dubbo提供了多種均衡策略，缺省為random隨機調用。
Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態調整提供者權重。
RoundRobin LoadBalance
輪循，按公約后的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前后計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大。
ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一臺提供者掛時，原本發往該提供者的請求，基于虛擬節點，平攤到其它提供者，不會引起劇烈變動。

集群容錯模式：
Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器。(缺省)
通常用于讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。正是文章剛開始說的那種情況.
Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用于非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用于寫入審計日志等操作。
Failback Cluster
失敗自動恢復，后臺記錄失敗請求，定時重發。
通常用于消息通知操作。
Forking Cluster
并行調用多個服務器，只要一個成功即返回。
通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設置最大并行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
通常用于通知所有提供者更新緩存或日志等本地資源信息。
重試次數配置如：(failover集群模式生效)

Dubbo的集群容錯和負載均衡同樣也是Dubbo本身的高級特性.正如我們在說自定義擴展的時候一樣,這兩個特征同樣也可以進行自定義擴展,用戶可以根據自己實際的需求來擴展他們從而滿足項目的實際需求.

13.Dubbo的優點是什么？Dubbo對分布式事務是如何處理的？

Dubbo的優點：
1）Dubbo具有調度、發現、監控、治理等功能，支持相當豐富的服務治理能力
2）集群容錯
當服務調用失敗時，根據我們的業務不同，可以使用不同的策略來應對這種失敗。
3）負載均衡
當同一個服務有多個提供者在提供服務時， 客戶端如何正確的選擇提供者實現負載均衡dubbo也給我們提供了幾種方案
4）多協議
dubbo提供了多種協議給用戶選擇， 如Dubbo協議、Hessian協議、HTTP協議、RMI協議、WebService協議、Thrift協議、Memcached協議、Redis協議。

Dubbo對分布式事務的處理：
分布式事務暫不支持。用戶可以自己根據實際情況來實現分布式事務，比如：
1）結合RocketMQ消息中間件實現的可靠消息最終一致性
2）TCC補償性事務解決方案
3）最大努力通知型方案

http://bbs.itheima.com/forum.php?mod=viewthread&tid=386556

https://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html

zookeeper

一般，zookeeper配合dubbo使用，作為注冊中心。

zookeeper是一種為分布式應用所設計的高可用、高性能且一致的開源協調服務，它提供了一項基本服務：分布式鎖服務。由于zookeeper的開源特性，后來我們的開發者在分布式鎖的基礎上，摸索出了其他的使用方法：配置服務、組服務、分布式消息隊列、分布式通知/協調等。

注意：zookeeper性能上的特點決定了它能夠用在大型的、分布式的系統當中。從可靠性方面來說，它并不會因為一個節點的錯誤而崩潰。除此之外，它嚴格的序列訪問控制意味著復雜的控制原語可以應用在客戶端上。zookeeper在一致性、可用性、容錯性的保證，也是zookeeper的成功之處，它獲得的一切成功都與它采用的協議-Zab協議是密不可分的。

zookeeper集群的角色主要有一下三類：

1.leader角色： leader服務器是整個zookeeper集群的核心，主要的工作任務有兩項1.事務請求的唯一調度和處理者，保證集群事務處理的順序性2.集群內部各服務器的調度者。

2.follower角色：follower角色的主要職責是1.處理客戶端非事務請求，轉發事務請求給leader服務器2.參與事務請求proposal的投票（需要半數以上服務器通過才能通知leader commit數據；leader發起的提案，要求follower投票）3.參與leader選舉的投票

3.observer角色： observer是zookeeper3.3開始引入的一個全新的服務器角色，從字面來理解，該角色充當了觀察者的角色。觀察zookeeper集群中的最新狀態變化并將這些狀態變化同步到observer服務器上。observer的工作原理與follower角色基本一致，而它和follwer角色唯一的不同在于observer不參與任何形式的投票，包括事務請求proposal的投票和leader選舉的投票。簡單來說，observer服務器只提供非事務請求服務，通常在于不影響集群事務處理能力的前提下提升集群非事務處理的能力。

總結

以上是生活随笔為你收集整理的Dubbo Zookeeper的全部內容，希望文章能夠幫你解決所遇到的問題。

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