**：
建立乙個遊戲系統，其將執行在網際網路的環境中。客戶端通過www
服務或特定的客戶端軟體連線到遊戲伺服器，隨著流量的增加，系統不斷的膨脹，最終後台資料、業務邏輯被分布式的部署。然而相比中心化的系統，複雜度被無可避免的增大了，該如何降低各個元件之間的耦合度。
需要保證可伸縮性、可維護性、可更新性，需要將服務劃分為各個相對獨立的元件，元件被分布式的部署，它們之間通過程序間通訊方式實現互動。服務的增加、刪除、改變都應該被支援。理想情況，以開發者的角度看，集中化的系統和分布式的系統在中心邏輯上沒有什麼不同。為實現這個目標：
l 可以遠端的訪問服務，而對於訪問者，服務的位置應該是透明的。
l 提供服務的元件可以增加、刪除、改變，而且這些在執行期同樣應該被支援。
l 訪問服務的客戶端不應該關心服務的實現細節。
引入乙個broker
元件，解耦客戶端和服務端。服務端註冊自己到broker，通過暴露介面的方式允許客戶端接入服務。客戶端是通過broker傳送請求的，broker**請求道服務端，並將請求的結果或異常回發給客戶端。通過使用broker模式，應用可以通過傳送訊息訪問遠端的服務。
這一架構模式允許動態的改變、新增、刪除服務端，從客戶端的角度，這些都是透明的。
broker模式定義了6中類
：client，server，client_proxy，server_proxy，broker，bridge。
l 責任：處理特定領域的問題，實現服務的細節，註冊自己到broker
，處理請求並返回結果或異常。
l 協作類：server_proxy
，broker
client是需要訪問遠端服務的應用程式，為此，
client
傳送請求到
broker
，並從broker
上接收響應或異常。
client
和server
只是邏輯上相關而已，實際上
client
並不知道
server
的確切位置。
l 責任：1.
實現使用者端功能，
2. 傳送請求到
broker
，3.
接收相應和異常。
l 協作類：broker
，client_proxy
broker可以被看成訊息**器。
broker
也負責一些控制和管理操作。它能夠定位服務端的位置，若發生異常，能夠將異常捕獲傳給
client
。broker
需要提供註冊服務的介面給
server
。如果請求來自其他的
broker
，本地的
broker
需要**請求並最終將結果或異常回應給相應的遠端
broker
。broker
提供的服務和
name service
非常相像（如
dns、
ldap
）。l
責任：1.
註冊服務。
2. 提供服務
api。
3. **訊息。
4. 容錯處理。
5. 與其他
broker
的互動。
6。 定位服務。
l 協作類：client_proxy,server_proxy,bridge
連繫client
和broker
，這一層保證了通訊的透明性，使
client
呼叫遠端服務就像呼叫本地的服務一樣。
l 責任：1.
封裝特定的系統呼叫。
2. 封裝通訊的引數、控制資訊等。
l 協作類：client,broker
。
server_proxy是與
client_proxy
相對應的，它接受請求，解包訊息，解析出引數並呼叫服務的實現介面。
l 責任：1.
封裝特定的系統呼叫。
2. 封裝通訊的引數、控制資訊等。
3. 呼叫
server
的服務介面。
l 協作類：server,broker
。
bridge用來連線各個
broker
，一般這個元件是可選的。當系統是發雜的網路組成時，有可能需要這一角色。
l 責任：1.
封裝特定的網路特性。
2. 傳遞
broker
之間的通訊。
l 協作類：broker
。
直接通訊方式。client
和server
相互理解他們之間的通訊協議。
broker
主要完成
client
和server
之間的握手。之後所有的訊息、異常都是由
client
與server
直接互動。（想象
dns）。簡單物件互動如圖：
l broker啟動，完成自身的初始化，之後進入事件迴圈，等待訊息到來。
l server啟動，首先執行自身的初始化，然後註冊自己到
broker。l
broker接收
server
的註冊請求，將其加入到可使用服務的列表，並回應
ack給
server。l
server接收
ack，進入事件監聽迴圈，等待訊息到來。
l client呼叫遠端服務物件的方法，
client_proxy
封裝訊息請其傳送給
broker。l
broker查詢可使用的
server
，將請求**給
server。l
server_proxy解析訊息，分離出引數和控制資訊，並呼叫特定的
server
實現介面。
server
處理完的結果通過
server_proxy
封裝成訊息**到
server。l
broker將相應訊息**給正確的
client_proxy
，client
受到響應繼續其他邏輯。
簡單物件互動如圖：
l broker a接收到請求，交由server處理，但是發現該server位於其他的網路節點。l
broker a將請求**給bridge a，bridge a將請求進行必要的格式化，傳送給bridge b。
l bridge b將請求進行必要的格式化，轉化成broker b可以理解的格式，並**給broker b。broker b執行場景二中的過程，處理的結果按如上逆序返回。
簡單物件互動如圖：
u 優點：
1. 服務的位置透明性。
2. 元件的可變性及擴充套件性。由於server是註冊到broker上的，所以server可以動態的增加、刪除、改變。
3. broker之間可互動。
4. 可重用性。
5. 由於元件的耦合度較小，除錯和測試的工作也是可控的。
u 缺點:
1. 效率；增加了一層broker的訊息**，效率有所降低。
2. 容錯能力必須要特別考慮。
3. 除錯和測試的工作加大。
分布式服務之邊車模式
邊車 就是在原來二輪電單車旁邊增加乙個座位成了三輪電單車，增加的一部分稱為邊車 邊車模式 對現有的服務增加額外的功能，這些功能並不影響業務邏輯，例如增加日誌，限流 熔斷 服務的註冊和服務發現有專門服務來實現。像程式中的控制和業務邏輯分離 controller 和 service 層分離 這樣大大降低...
分布式鎖 哨兵模式 分布式鎖實現原理
背景 記錄對分布式鎖的相關理解，不斷提公升自己 可重入鎖 為什麼不建議使用redis分布鎖 主從切換可能丟失鎖資訊 考慮一下這樣的場景 在分布式環境中，很多併發需要鎖來同步，當使用redis分布式鎖，通用的做法是使用redis的setnx key value px 這樣的命令，設定乙個字段，當設定成...
Hadoop偽分布式模式測試
配置系統 conf core site.xml fs.default.name hdfs localhost 9000 conf hdfs site.xml dfs.replication1 conf mapred site.xml mapred.job.tracker localhost 9001...