31.dubbo注冊中心挂了後能夠繼續通信麼？
注冊中心挂了之後，可以繼續通信。因為初始化的時候，消費者已經将提供者的位址等資訊拉取到本地緩存。
32.dubbo支援哪些序列化協定，知道PB麼？為什麼 PB 的效率是最高的？
1）dubbo 協定
hessian序列化協定 ，單一長連接配接，進行的是 NIO 異步通信
2）hessian 協定
hessian ，多個短連接配接，适用于提供者數量比消費者數量還多的情況，适用于檔案的傳輸，一般較少用。
3）rmi 協定
Java 二進制序列化，多個短連接配接，适合消費者和提供者數量差不多的情況，适用于檔案的傳輸，一般較少用。
4）http 協定
json 序列化。
5）webservice
SOAP 文本序列化。
Protocal Buffer 是一種輕量并且高效的結構化資料存儲格式，性能比 XML 和 JSON 快上了 20~100 倍。
第一，它使用 proto 編譯器，自動進行序列化和反序列化，速度非常快。第二，它的資料壓縮效果好，就是說它序列化後的資料量體積小，傳輸帶寬和速度上會有優化。
33.dubbo 負載均衡政策和叢集容錯政策都有哪些？動态代理政策呢？
負載均衡政策
1）random loadbalance 随機調用（預設）
可以對 provider 不同執行個體設定不同的權重，權重越大配置設定的流量就越高。
2）roundrobin loadbalance 輪訓調用
均勻地将流量打到各個機器上（如果各個機器的性能不一樣，容易導緻性能差的機器負載過高，可以調整權重，讓性能差的機器承載權重小一些）。
3）leastactive loadbalance 最小活躍樹
給性能差的機器更少的請求。
4）consistanthash loadbalance 一緻性 Hash
使用一緻性 Hash 算法，相同參數的請求一定分發到一個 provider 上去。
dubbo 叢集容錯政策
1）failover cluster 故障轉移模式（預設）
失敗自動重試其他機器。
2）failfast cluster 快速失敗模式
一次調用失敗就立即失敗。
3）failsafe cluster 失效安全模式
出現異常時忽略掉（常用于不重要的接口調用）。
4）failback cluster 自動恢複模式
失敗了背景自動記錄請求，然後定時重發。（适用于寫消息隊列）
5）forking cluster 分叉模式
并行調用多個 provider，隻要一個成功就立即傳回。（實時性要求較高的讀操作，但是需要消耗更多的資源）
6）broadcast cluster 廣播模式
廣播調用所有提供者，逐個調用（任意一台報錯則報錯）。通常用于通知所有提供者更新緩存或日志等本地資源資訊。
dubbo動态代理政策
預設使用 javassist 動态位元組碼（高層的Java位元組碼處理類庫，能運作時動态生成、修改類）生成，建立代理類。可以通過 spi 擴充機制配置自己的動态代理政策。
34.dubbo 的 spi 思想是什麼？
spi（service provider interface），如果一個接口存在多個實作類，那麼在系統運作的時候需要根據指定的配置或者是預設的配置，去找到對應的實作類加載進來，然後用這個實作類的執行個體對象。
dubbo自己實作的一套 spi 機制-Protocol（協定）。
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
根據以上代碼可知Protocol 接口在系統運作時，dubbo 會判斷一下選用哪個實作類來執行個體化對象來使用。
dubbo 的
/META_INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol
檔案中存在以下配置，通過 SPI 機制來提供實作類，實作類是通過 dubbo 作為預設 key 去配置檔案裡擷取，然後選用該實作類來執行個體化對象。
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol（預設）
http=com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
35.如何進行服務治理、服務降級、失敗重試以及逾時重試
服務治理
1）鍊路治理
各個服務之間的互動根據一個統一标示串聯起來，采集資訊生成各個服務之間的依賴關系和調用鍊路。
2）服務通路壓力和通路延時
自動統計各個接口和服務之間的調用次數以及通路延時，友善實時了解線上情況，并可以根據資料回報完成接口優化和擴容
3）調用鍊路失敗監控和報警
監控接口錯誤日志和成功率，友善實時了解線上問題，及時排查和修複
4）服務鑒權
系統間互相調用引入鑒權，提高安全性。
服務降級
dubbo：
1）mock配置，如下
<dubbo:reference id="testService" inter timeout="10000" check="false" mock="return null">
2）自定義mock業務處理類，實作TestServiceMock（接口名+Mock字尾）
<dubbo:reference id="testService" inter check="false" mock="true" />
springcloud：
1）feign元件，自定義一個類實作FallbackFactory
2）zuul網關，自定義一個類實作ZuulFallbackProvider接口
失敗重試以及逾時重試
dubbo：
<dubbo:reference id=“testService” interface=“com.test.service.TestService” check=“false” retries=“3” timeout=“200”/>
springcloud：
1）ribbon 配置
MaxAutoRetries: 1 #最大重試次數
MaxAutoRetriesNextServer: 1 #重試負載均衡其他的執行個體最大重試次數
OkToRetryOnAllOperations: false #是否所有操作都重試
36.分布式服務接口請求的順序性如何保證
1）分布式鎖（redis、zookeeper等實作），會導緻系統複雜度上升、效率低下、熱點資料壓力過大等問題
2）一緻性 hash 負載均衡政策，将具有相同特征的資料交由一個節點處理，但是同樣存在熱點資料壓力
3）業務邏輯合并，避免過多要求順序性的接口請求
37.如何自己設計一個類似 dubbo 的 rpc 架構
1）服務提供者初始化、注冊、以及響應遠端調用的實作
2）服務消費者訂閱注冊中心、監聽服務提供者的變化的實作
3）動态代理的實作。
4）負載均衡、序列化協定
5）實作螢幕，負責統計服務的消費和調用情況
38.springcloud和dubbo
Dubbo是高性能服務架構，SpringCloud則是一個完整的分布式一站式架構，基于SpringBoot的便利性融合了一整套實作微服務的架構，除了Dubbo已有的功能外，還提供管控台，斷路器，分布式配置服務等服務。
Dubbo底層使用Netty基于TCP協定傳輸+Hession序列化完成RPC通信，SpringCloud是基于Http協定+rest接口調用遠端過程的通信。Http請求會有更大的封包，占的帶寬也會更多。但是REST相比RPC更為靈活，不存在代碼級别的強依賴，更加靈活。
39.threadlocal應用解決了什麼問題
1）使用
ThreadLocal
代替
Synchronized
來保證線程安全，每個線程都持有一份變量，通路時互不影響。
2）
ThreadLocal
為變量在每個線程中建立了一個副本，是以每個線程可以通路自己内部的副本變量。
40.分布式事務
兩階段送出（2PC）
兩階段送出，通過引入協調者來協調參與者，并最終決定這些參與者是否要真正執行事務。
第一階段，協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。
第二階段，如果事務在每個參與者上都執行成功，事務協調者發送通知讓參與者送出事務。如果一旦有參與者執行失敗，協調者發送通知讓參與者復原事務。
存在的問題：
1）所有事務參與者在等待其它參與者響應的時候都處于同步阻塞狀态，效率低。
2）協調者存在單點問題，一旦挂了會造成很大影響。
3） 第二階段如果協調者部分 Commit 消息發送失敗，部有收到消息的參與者會出現問題。
4）沒有完善的容錯機制。
補償事務（TCC）
針對每個操作，都要注冊一個與其對應的确認和撤銷操作。
Try階段通知業務系統做檢測及資源預留。（預設隻要Try成功，第二階段Confirm就成功）
Confirm階段，業務系統做确認送出
Cancel 階段，業務執行錯誤，復原的狀态下執行的業務取消并預留資源釋放。
存在的問題：
1）Confirm和Cancel都有可能失敗
2）需要多寫很多代碼
業務輪訓表+消息隊列
建立業務輪訓表儲存業務執行狀态，按異步的方式協調完成事務，實作最終一緻性。
存在的問題：
1）輪訓表會耦合業務，不夠靈活。
2）會出現頻繁讀寫資料庫記錄，高并發可能存在平靜
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)