經過前面的介紹，我想大家都已經知道了在zookeeper集群當中有兩種角色leader和follower。leader可以接受client 請求，也接收其他server**的寫請求，負責更新系統狀態。 follower也可以接收client請求，如果是寫請求將**給leader來更新系統狀態，讀請求則由follower的記憶體資料庫直接響應。 zookeeper集群如圖1.1所示。
圖 1.1 zookeeper集群服務
但在zookeeper的3.3.3版本以後，zookeeper中又新增了一種新角色observer。observer的作用同follower類似，唯一區別就是它不參與選主過程。那麼，我們就可以根據該特性將zk集群中的server分為兩種：
(1) 投票server：leader、follower
(2) 非投票server：observer
(1) zookeeper可伸縮性
那麼，zookeeper為什麼要引入observer這個角色呢？其實在zookeeper中引入observer，主要是為了使 zookeeper具有更好的可伸縮性。那麼，何為可伸縮性？關於伸縮性，對於不同的人意味著不同的事情。 而在這裡是說，如果我們的工作負載可以通過給系統分配更多的資源來分擔，那麼這個系統就是可伸縮的；乙個不可伸縮的系統卻無法通過增加資源來提公升效能，甚 至會在工作負載增加時，效能會急劇下降。
在observer出現以前，zookeeper的伸縮性由follower來實現，我們可以通過新增follower節點的數量來保證 zookeeper服務的讀效能。但是隨著follower節點數量的增加，zookeeper服務的寫效能受到了影響。為什麼會出現這種情況？在此，我 們需要首先了解一下這個」zk服務」是如何工作的。
(2) zk服務過程
zookeeper服務中的每個server可服務於多個client，並且client可連線到zk服務中的任一台server來提交請求。若是讀請求，則由每台server的本地副本資料庫直接響應。若是改變server狀態的寫請求，需要通過一致性協議來處理，這個協議就是我們前面介紹的zab協議。
簡單來說，zab協議規定：來自client的所有寫請求，都要**給zk服務中唯一的server—leader， 由leader根據該請求發起乙個proposal。然後，其他的server對該proposal進行vote。之後，leader對vote進行收 集，當vote數量過半時leader會向所有的server傳送乙個通知訊息。最後，當client所連線的server收到該訊息時，會把該操作更新 到記憶體中並對client的寫請求做出回應。該工作流程如下圖1.2所示。
圖1.2 zk 寫請求工作流程圖
從圖中我們可以看出， zookeeper 伺服器在上述協議中實際扮演了兩個職能。它們一方面從客戶端接受連線與操作請求，另一方面對操作結果進行投票。這兩個職能在 zookeeper集群擴充套件的時候彼此制約。例如，當我們希望增加 zk服務中client數量的時候，那麼我們就需要增加server的數量，來支援這麼多的客戶端。然而，從zab協議對寫請求的處理過程中我們可以發 現，增加伺服器的數量，則增加了對協議中投票過程的壓力。因為leader節點必須等待集群中過半server響應投票，於是節點的增加使得部分計算機運 行較慢，從而拖慢整個投票過程的可能性也隨之提高，寫操作也會隨之下降。這正是我們在實際操作中看到的問題——隨著 zookeeper 集群變大，寫操作的吞吐量會下降。
(3) zookeeper擴充套件
所以，我們不得不，在增加client數量的期望和我們希望保持較好吞吐效能的期望間進行權衡。要打破這一耦合關係，我們引入了不參與投票的服務 器，稱為 observer。 observer可以接受客戶端的連線，並將寫請求**給leader節點。但是，leader節點不會要求 observer參加投票。相反，observer不參與投票過程，僅僅在上述第3歩那樣，和其他服務節點一起得到投票結果。
圖 1.3 observer 寫吞吐量測試
圖1.3 顯示了乙個簡單評測的結果。縱軸是，單一客戶端能夠發出的每秒鐘同步寫操作的數量。橫軸是 zookeeper 集群的尺寸。藍色的是每個伺服器都是投票server的情況，而綠色的則只有三個是投票server，其它都是 observer。從圖中我們可以看出，我們在擴充 observer時寫效能幾乎可以保持不便。但是，如果擴充套件投票server的數量，寫效能會明顯下降，顯然 observers 是有效的。
這個簡單的擴充套件，給 zookeeper 的可伸縮性帶來了全新的映象。我們現在可以加入很多 observer 節點，而無須擔心嚴重影響寫吞吐量。但他並非是無懈可擊的，因為協議中的通知階段，仍然與伺服器的數量呈線性關係。但是，這裡的序列開銷非常低。因此，我 們可以認為在通知伺服器階段的開銷無法成為主要瓶頸。
(1) observer提公升讀效能的可伸縮性
應對client的數量增加，是 observer的乙個重要用例，但是實際上它還給集群帶來很多其它的好處。observer作為zookeeper的乙個優化，observer伺服器可以直接獲取leader的本地資料儲存，而無需經過投票過程。但這也面臨一定的」時光旅行」風險，也就是說：可能在讀到新值之後又讀到老值。但這只在伺服器故障時才會發生事實上，在這種情況下，client可以通過」sync」操作來保證下乙個值是最新的。
因此，在大量讀操作的工作負載下，observer會使zookeeper的效能得到巨大提公升。若要增加投票server數量來承擔讀操作，那麼就 會影響zookeeper服務的寫效能。而且observer允許我們將讀效能和寫效能分開，這使zookeeper更適用於一些以讀為主的應用場景。
(2) observer提供了廣域網能力
observer還能做更多。observer對於跨廣域網連線的client來說是很好的候選方案。observer可作為候選方案，原因有三：
① 為了獲得很好的讀效能，有必要讓客戶端離伺服器盡量近，這樣往返時延不會太高。然而，將 zookeeper 集群分散到兩個集群是非常不可取的設計，因為良好配置的 zookeeper 應該讓投票伺服器間用低時延連線互連——否則，我們將會遇到上面提到的低反映速度的問題。
② 而observer 可以被部署在，需要訪問 zookeeper 的任意資料中心中。這樣，投票協議不會受到資料中心間鏈路的高時延的影響，效能得到提公升。投票過程中 observer 和領導節點間的訊息遠少於投票伺服器和領導節點間的訊息。這有助於在遠端資料中心高寫負載的情況下降低頻寬需求。
③ 由於observer即使失效也不會影響到投票集群，這樣如果資料中心間鏈路發生故障，不會影響到服務本身的可用性。這種故障的發生概率要遠高於乙個資料中心中機架間的連線的故障概率，所以不依賴於這種鏈路是個優點。
前面介紹了zookeeper集群中的幾種角色，接下來給大家來介紹一下如何利用這些角色，來搭建乙個效能良好的zookeeper集群。我以乙個專案為例，給大家分析一下該如何規劃我們的zookeeper集群。
假設我們的專案需要進行跨機房操作，我們的總部機房設在杭州，但他還要同美國，青島等多個機房之間進行資料互動。但機房之間的網路延遲都比較大，比如中美機房走海底光纜有ping操作200ms的延遲，杭州和青島機房有70ms的延遲。為了提公升系統的網路效能，我們在部署zookeeper網路時會在每個機房部署節點，多個機房之間再組成乙個大的網路，來保證整個zk集群資料一致性。
根據前面的介紹，最後的部署結構就會是：
(總部) 杭州機房 >=3臺 ：由leader/follower構成的投票集群
(分支) 青島機房 >=1臺 ：由observer構成的zk集群
(分支) 美國機房 >=1臺 : 由observer構成的zk集群
圖 3.1 zookeeper集群部署圖
從圖中我們可以看出，我們在單個機房內組成乙個投票集群，外圍的機房都會是乙個observer集群和投票集群進行資料互動。 至於這樣部署的一些好處，大家自己根據我前面對zookeeper角色的介紹，對比著體會一下，我想這樣更能幫助大家理解zookeeper。而且針對這 樣的部署結構，我們會引入乙個優先集群問題： 比如在美國機房的client，需要優先去訪問本機房的zk集群，訪問不到才去訪問hz(總部)機房。
ZooKeeper（八）伸縮性
經過前面的介紹，我想大家都已經知道了在zookeeper集群當中有兩種角色leader和follower。leader可以接受client 請求，也接收其他server 的寫請求，負責更新系統狀態。follower也可以接收client請求，如果是寫請求將 給leader來更新系統狀態，讀請求則由f...
系統伸縮性
系統伸縮性，是指在不改變系統軟硬體設計，僅僅通過新增伺服器的情況下，就能提公升系統的處理能力。系統成為大型的，分為2種，一種是開始就設計成大型的，例如12306 設計之初就要考慮能併發處理多少請求，要儲存多少資料。另外一種是從小系統慢慢演化成大型系統的，例如google 一開始只是幾台伺服器，然後隨...
可伸縮性搜尋框 Duration
最近在設計班級 的首頁，模仿別人部落格裡使用到的可伸縮的搜尋框，剛開始想想覺得挺奇妙的，後來發現這其實不難，利用之前 css 學過的 duration 就可以實現了。下面是我從班級首頁中抽出來的搜尋框製作成的 demo，跟大家分享下。我們先看看 css box assistive searchare...