一、架構
二、流程解析
1.在zookeeper註冊生產者，給生產者分配標識key
注：不同的生產者可以有不同的key，也可以選擇使用相同的key。一般是類似功能的生產者分配一個key
2.在zookeeper註冊消費者，也給消費者分配key
注：key的
3.消費者拿給生產者分配的key去訪問對應的生產者
4.生產者先對消費者分發一些服務器，再對請求的數據進行一系列計算，判斷分發到哪個服務器。同時將消費者對應請求分發到的服務器域名記入緩存，下次直接訪問。
三、要點解析
zookeeper：ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，它的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。zookeeper中可以會記錄可以使用的服務器，可以使用的爲綠色，出現問題不能使用的爲紅色，down掉的會消失
生產者：將接口封裝成jar包提供給ZooKeeper，同時ZooKeeper還封裝了要訪問的各個服務器的域名。
消費者：要使用這些接口的使用者
通信方式：ZooKeeper和生產者消費者之間以RPC協議通信
RPC協議： 一種進程間通信方式。允許像調用本地服務一樣調用遠程服務。
RPC框架的主要目標：讓遠程服務調用更簡單、透明。RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進制）和通信細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠程服務接口即可，並不需要關心底層通信細節和調用過程，所以具體的協議其實是自定義的。
注：生產者同時也可以是消費者，消費者也同時可以是生產者，所以每個消費者或生產者最多擁有兩個key
如果生產者有一個服務器出問題了怎麼辦？
1.消費者第一次請求失敗後，一般可以再有一次請求的機會，若此次失敗，判斷該服務器出問題，會告知消費者此服務器出現問題,請求會往有類似功能的另一個服務器上分配，同時更新緩存（幾次請求機會自己設置）
2.該服務器出問題的數據會往ZooKeeper同步，若該服務器修復成功，消費者會再次通過ZooKeeper訪問生產者的服務器，訪問的域名依舊記錄在緩存。
消費者和生產者如何知道這個服務器出問題？
當有一個服務器出問題時，zookeeper會記錄該服務器出現問題。
這時候有兩種渠道讓消費者和生產者知道出現問題：
1.zookeeper實時向各個消費者和生產者發送推送告訴他們出現問題
2.消費者或生產者訪問zookeeper時瞭解到出現問題