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配置，如下
<reference>
2）自定義mock業務處理類，實現TestServiceMock（接口名+Mock後綴）
springcloud：
1）feign組件，自定義一個類實現FallbackFactory
2）zuul網關，自定義一個類實現ZuulFallbackProvider接口
失敗重試以及超時重試
dubbo：
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）會出現頻繁讀寫數據庫記錄，高併發可能存在平靜
閱讀更多 加班狗的微博 的文章
