分佈式方面的問題收集

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

http://www.javashuo.com/article/p-kfsehtfq-gt.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