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

Dubbo

Dubbo只支持Java語言。

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

• From：hongda整理的面試題

分布式方面的問題收集

1.Dubbo簡介：

調用關系：

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

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

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

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

3 dubbo連接注冊中心和直連的區(qū)別

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

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

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

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

默認使用Hessian,現(xiàn)在高效的有Kryo和FST

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

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

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

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

但是如果不合理的配置重試次數(shù)，當失敗時會進行重試多次，這樣在某個時間點出現(xiàn)性能問題，調用方再連續(xù)重復調用，系統(tǒng)請求變?yōu)檎Ｖ档膔etries倍，系統(tǒng)壓力會大增，容易引起服務雪崩，需要根據(jù)業(yè)務情況規(guī)劃好如何進行異常處理，何時進行重試。

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

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

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

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

dubbo協(xié)議：

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

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

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

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

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

9.為什么不能傳大包：

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

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

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

網(wǎng)絡服務在處理數(shù)以萬計的客戶端連接時，往往出現(xiàn)效率底下甚至完全癱瘓，這被成為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
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態(tài)調整提供者權重。
RoundRobin LoadBalance
輪循，按公約后的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
LeastActive LoadBalance
最少活躍調用數(shù)，相同活躍數(shù)的隨機，活躍數(shù)指調用前后計數(shù)差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數(shù)差會越大。
ConsistentHash LoadBalance
一致性Hash，相同參數(shù)的請求總是發(fā)到同一提供者。
當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。

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

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

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

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

Dubbo對分布式事務的處理：
分布式事務暫不支持。用戶可以自己根據(jù)實際情況來實現(xiàn)分布式事務，比如：
1）結合RocketMQ消息中間件實現(xiàn)的可靠消息最終一致性
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是一種為分布式應用所設計的高可用、高性能且一致的開源協(xié)調服務，它提供了一項基本服務：分布式鎖服務。由于zookeeper的開源特性，后來我們的開發(fā)者在分布式鎖的基礎上，摸索出了其他的使用方法：配置服務、組服務、分布式消息隊列、分布式通知/協(xié)調等。

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

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

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

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

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

總結

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

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