Zookeeper簡介

對HTTP服務的遠程調用

	Apache	Square	Netflix
組件	HttpClient	OkHttp	Feign

RestTemplate 是 Spring 提供的用來訪問 REST 服務的客戶端，利用了 JDK 或HttpClient 、OkHttp 等來實現 http 遠程調用

ClientHttpRequestFactory接口的主要實現類

	JDK	Apache	OkHttp3
	SimpleClientHttpRequestFactory	HttpComponentsClientHttpRequestFactory	OkHttp3ClientHttpRequestFactory

HTTP 和 RPC 框架的區別

HTTP	RPC
成熟穩定、使用實現簡單、被普遍支持、兼容性良好、防火牆友好、 消息的可讀性高。因此 http 協議在開放 API、跨平臺的服務間調用、對性能要求不苛刻的場景中有着普遍的使用。	高效的網絡傳輸模型（常使用 NIO 來實現），以及針對服務調用場景專門設 計協議和高效的序列化技術

註冊中心的實現

Dubbo 體系中的 Zookeeper、Spring Cloud 中的 Eureka 和 Consul

 

分佈式一致性的本質，就是在分佈式系統中，多個節點就某一個提議如何達成一致

 

zookeeper 的設計

    防止單點故障 , 常見的解決單點問題的方式就是集羣

集羣須要知足的功能

1. 集羣中要有主節點和從節點（也就是集羣要有角色）

2. 集羣要能作到數據同步，當主節點出現故障時，從節點可以頂替主節點繼續工做， 數據必需要主節點保持一直

3. 主節點掛了之後，從節點如何接替成爲主節點？ 是人工干預？仍是自動選舉

Leader 角色

    Leader 服務器是整個 zookeeper 集羣的核心，主要的工做任務有兩項

        1. 事物請求的惟一調度和處理者，保證集羣事物處理的順序性

        2. 集羣內部各服務器的調度者

Follower 角色

    Follower 角色的主要職責是

        1. 處理客戶端非事物請求(查詢)、轉發事物請求(更新、刪除、新增)給 leader 服務器

        2. 參與事物請求 Proposal 的投票（須要半數以上服務器經過才能通知 leader commit 數據; Leader 發起的提案，要求 Follower 投票）

        3. 參與 Leader 選舉的投票

數據同步

要實現各個節點的數據 一致性，就勢必要一個 leader 節點負責協調和數據同步操做

分佈式事務的數據一致性

    

Observer 角色

Observer 是 zookeeper3.3 開始引入的一個全新的服務器角色，從字面來理解，該角色充當 了觀察者的角色。

觀察 zookeeper 集羣中的最新狀態變化並將這些狀態變化同步到 observer 服務器上。Observer 的工做原理與 follower 角色基本一致，而它和 follower 角色惟一的不一樣在於observer 不參與任何形式的投票，包括事物請求 Proposal 的投票和 leader 選舉的投票。簡單來講，observer 服務器只提供非事物請求服務，一般在於不影響集羣事物處理能力的前提下提高集羣非事物處理的能力

leader 選舉

當 leader 掛了，須要從其餘 follower 節點中選擇一個新的節點進行處理，這個時候就須要涉 及到 leader 選舉

集羣組成

    一般 zookeeper 是由 2n+1 臺 server 組成，每一個 server 都知道彼此的存在。每一個 server 都維護的內存狀態鏡像以及持久化存儲的事務日誌和快照。對於 2n+1 臺 server，只要有 n+1臺（大多數）server 可用，整個系統保持可用。一個 zookeeper 集羣若是要對外提供可用的服務，那麼集羣中必需要有 過半 的機器正常工做而且彼此之間可以正常通訊，所以 3 臺機器構成的 zookeeper 集羣，可以在掛掉一臺機器後依然正常工做。一個 5 臺機器集羣的服務，可以對 2 臺機器怪調的狀況下進行容災。若是一臺由 6 臺服務構成的集羣，一樣只能掛掉 2 臺機器。所以，5 臺和 6 臺在容災能力上並無明顯優點，反而增長了網絡通訊負擔。系統啓動時，集羣中的 server 會選舉出一臺server 爲 Leader，其它的就做爲 follower（這裏先不考慮 observer 角色）。 一個節點要成爲集羣中的 leader，須要有超過半數的節點支持，這個涉及到 leader 選舉算法。同時也涉及到事務請求的提交投票