dubbo
1，rpc的分布式集群支持：負載均衡是對外提供一個公共地址，請求過來時通過輪詢、隨機的形式來分攤壓力，掛一台補一台
2，結合zookeeper解藕：(提供者注冊和消費者訂閱)客戶端和服務端啟動的時候都會把自己的機器IP注冊到zookeeper上。客戶端會把zk上的服務端ip拉到磁盤上，並記錄哪些ip提供哪些服務（服務端啟動的時候暴露給zk）。
然后調用的時候客戶端會根據ip調用服務端的服務，這時候即使zk掛掉也沒關系。
3：長連接通訊：nio通信抽象封裝（暫時沒接觸）
可用場景：
1，商城做活動流量暴漲：防止系統崩掉 可以通過dubbo來控制訪問量
2，分布式服務器rpc過程調用壓力分擔
mq的問題的起源：
對分布式系統研究的 CAP定律 分布式事務有強一致，弱一致，和最終一致性 只能同時滿足2點，三者不能兼得
比如有訂單，庫存兩個數據，一個下單過程簡化為，加一個訂單，減一個庫存。 而訂單和庫存是獨立的服務，那怎么保證數據一致性
保證兩個遠程調用“同時成功”，數據一致 當然失敗和超時都有可能 ，一般的解決方案，大多數的做法是借助mq來做最終一致
mq一個點對點一個是分布式訂閱：
mq的2個好處是：
1，消息不丟失：服務之間端掉消息會保存到mq中間件中，當消費者服務器恢復后就會重新發過去，消息不會丟失
2，異步處理：比如一個商城用戶購買產品后后台會去更新數據庫然后響應給客戶端，如果在高並發的情況下，
這樣更新數據庫響應客戶端會變慢，可以使用mq消息隊列的消費者進程中獲取數據來進行異步寫數據，由於消息對壘的服務處理速度遠快於數據庫，
因此響應延遲能得到有效改善