8.負載均衡
- Random，隨機，按權重配置隨機機率，調用量越大分佈越均勻，默認是這種方式
- RoundRobin，輪詢，按權重設置輪詢比例，若是存在比較慢的機器容易在這臺機器的請求阻塞較多
- LeastActive，最少活躍調用數，不支持權重，只能根據自動識別的活躍數分配，不能靈活調配
- ConsistentHash，一致性hash，對相同參數的請求路由到一個服務提供者上，若是有相似灰度發佈需求可採用
dubbo協議
缺省協議，使用基於mina1.1.7+hessian3.2.1的tbremoting交互。
鏈接個數：單鏈接
鏈接方式：長鏈接
傳輸協議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進制序列化
適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者沒法壓滿提供者，儘可能不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用web
爲何採用異步單一長鏈接？
由於服務的現狀大都是服務提供者少，一般只有幾臺機器，而服務的消費者多，可能整個網站都在訪問該服務，好比Morgan的提供者只有6臺提供者，卻有上百臺消費者，天天有1.5億次調用，若是採用常規的hessian服務，服務提供者很容易就被壓跨，經過單一鏈接，保證單一消費者不會壓死提供者，長鏈接，減小鏈接握手驗證等，並使用異步IO，複用線程池，防止C10K問題。redis
rmi協議
Java標準的遠程調用協議。
鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：TCP
傳輸方式：同步傳輸
序列化：Java標準二進制序列化
適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差很少，可傳文件。
適用場景：常規遠程服務方法調用，與原生RMI服務互操做瀏覽器
hessian協議
基於Hessian的遠程調用協議。
鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化
適用範圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
適用場景：需同時給應用程序和瀏覽器JS使用的服務。服務器
http協議
基於http表單的遠程調用協議。參見：[HTTP協議使用說明]
鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化
適用範圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
適用場景：需同時給應用程序和瀏覽器JS使用的服務負載均衡
webservice協議
基於WebService的遠程調用協議。
鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：SOAP文本序列化
適用場景：系統集成，跨語言調用dom
thrift協議
memcached協議
redis協議
3、集羣策略的種類異步
1）AvailableCluster: 獲取可用的調用。遍歷全部Invokers判斷Invoker.isAvalible,只要一個有爲true直接調用返回，無論成功與否；memcached
2）BroadcastCluster: 廣播調用。遍歷全部Invokers, 逐個調用每一個調用catch住異常不影響其餘invoker調用；網站
3）FailbackCluster: 失敗自動恢復， 對於invoker調用失敗， 後臺記錄失敗請求，任務定時重發, 一般用於通知；url
4）FailfastCluster: 快速失敗，只發起一次調用，失敗當即保錯，一般用於非冪等性操做；
5）FailoverCluster: 失敗轉移，當出現失敗，重試其它服務器，一般用於讀操做，但重試會帶來更長延遲；