zookeeper與分佈式系統

1.1. 分佈式系統基礎知識

   一個tomcat打天下的時代，不能說徹底淘汰了，在一個管理系統，小型項目中還常用，這並不過度，出於成本的考慮，這反而值得提倡。

   

1.1.1.   分佈式系統是什麼

分佈式系統：一個硬件或軟件組件分佈在不一樣的網絡計算機上，彼此之間僅僅經過消息傳遞進行通訊和協調的系統

 

這是分佈式系統，在不一樣的硬件，不一樣的軟件，不一樣的網絡，不一樣的計算機上，僅僅經過消息來進行通信與協調

 

這是他的特色，更細緻的看這些特色又能夠有：分佈性、對等性、併發性、缺少全局時鐘、

故障隨時會發生。

 

1.1.1.1. 分佈性

既然是分佈式系統，最顯著的特色確定就是分佈性，從簡單來看，若是咱們作的是個電商項目，整個項目會分紅不一樣的功能，專業點就不一樣的微服務，好比用戶微服務，產品微服務，訂單微服務，這些服務部署在不一樣的tomcat中，不一樣的服務器中，甚至不一樣的集羣中，整個架構都是分佈在不一樣的地方的，在空間上是隨意的，並且隨時會增長，刪除服務器節點，這是第一個特性

1.1.1.2. 對等性

對等性是分佈式設計的一個目標，仍是以電商網站爲例，來講明下什麼是對等性，要完成一個分佈式的系統架構，確定不是簡單的把一個大的單一系統拆分紅一個個微服務，而後部署在不一樣的服務器集羣就夠了，其中拆分完成的每個微服務都有可能發現問題，而致使整個電商網站出現功能的丟失。

好比訂單服務，爲了防止訂單服務出現問題，通常狀況須要有一個備份，在訂單服務出現問題的時候能頂替原來的訂單服務。

這就要求這兩個（或者2個以上）訂單服務徹底是對等的，功能徹底是一致的，其實這就是一種服務副本的冗餘。

還一種是數據副本的冗餘，好比數據庫，緩存等，都和上面說的訂單服務同樣，爲了安全考慮須要有徹底同樣的備份存在，這就是對等性的意思。

1.1.1.3. 併發性

併發性其實對咱們來講並不模式，在學習多線程的時候已經或多或少學習過，多線程是併發的基礎。

但如今咱們要接觸的不是多線程的角度，而是更高一層，從多進程，多JVM的角度，例如在一個分佈式系統中的多個節點，可能會併發地操做一些共享資源，如何準確並高效的協調分佈式併發操做。

後面實戰部分的分佈式鎖其實就是解決這問題的。

1.1.1.4. 缺少全局時鐘

在分佈式系統中，節點是可能反正任意位置的，而每一個位置，每一個節點都有本身的時間系統，所以在分佈式系統中，很難定義兩個事務糾結誰先誰後，緣由就是由於缺少一個全局的時鐘序列進行控制，固然，如今這已經不是什麼大問題了，已經有大把的時間服務器給系統調用

1.1.1.5. 故障隨時會發生

任何一個節點均可能出現停電，死機等現象，服務器集羣越多，出現故障的可能性就越大，隨着集羣數目的增長，出現故障甚至都會成爲一種常態，怎麼樣保證在系統出現故障，而系統仍是正常的訪問者是做爲系統架構師應該考慮的。

 

1.1.2. 大型網站架構圖回顧

知道什麼是分佈式系統，接下來具體來看下大型網站架構圖，這個圖在前面分佈式架構演進應該已經講過，首先整個架構分紅不少個層，應用層，服務層，基礎設施層與數據服務層，每一層都由若干節點組成，這是典型的分佈式架構，後面一大把的時間就是系統的學習裏面的每個部分

 

 

 

那麼zookeeper在其中又是扮演什麼角色呢，若是能夠把zk扮演成交警的角色，而各個節點就是馬路上的各類汽車（汽車，公交車），爲了保證整個交通（系統）的可用性，zookeeper必須知道每一節點的健康狀態（公交車是否出了問題，要派新的公交【服務註冊與發現】），公路在上下班高峯是否擁堵，在某一條很窄的路上只容許單獨一個方向的汽車經過【分佈式鎖】。

 

若是交通警察是交通系統的指揮官，而zookeeper就是各個節點組成分佈式系統的指揮官。

 

1.1.2.1. 分佈式系統協調「方法論」

 

1.1.2.1.1. 分佈式系統帶來的問題

若是把分佈式系統和平時的交通系統進行對比，哪怕再穩健的交通系統也會有交通事故，分佈式系統也有不少須要攻克的問題，好比：通信異常，網絡分區，三態，節點故障等。

 

1.1.2.1.1.1. 通訊異常

通信異常其實就是網絡異常，網絡系統自己是不可靠的，因爲分佈式系統須要經過網絡進行數據傳輸，網絡光纖，路由器等硬件不免出現問題。只要網絡出現問題，也就會影響消息的發送與接受過程，所以數據消息的丟失或者延長就會變得很是廣泛。

1.1.2.1.1.2. 網絡分區

網絡分區，其實就是腦裂現象，原本有一個交通警察，來管理整個片區的交通狀況，一切井井有理，忽然出現了停電，或者出現地震等天然災難，某些道路接受不到交通警察的指令，可能在這種狀況下，會出現一個零時工，片警零時來指揮交通。

 

但注意，原來的交通警察其實還在，只是通信系統中斷了，這時候就會出現問題了，在同一個片區的道路上有不一樣人在指揮，這樣必然引擎交通的阻塞混亂。

 

這種因爲種種問題致使同一個區域（分佈式集羣）有兩個相互衝突的負責人的時候就會出現這種精神分裂的狀況，在這裏稱爲腦裂，也叫網絡分區。

1.1.2.1.1.3. 三態

三態是什麼？三態其實就是成功，與失敗之外的第三種狀態，固然，確定不叫變態，而叫超時態。

在一個jvm中，應用程序調用一個方法函數後會獲得一個明確的相應，要麼成功，要麼失敗，而在分佈式系統中，雖然絕大多數狀況下可以接受到成功或者失敗的相應，但一旦網絡出現異常，就很是有可能出現超時，當出現這樣的超時現象，網絡通信的發起方，是沒法肯定請求是否成功處理的。

1.1.2.1.1.4. 節點故障

這個其實前面已經說過了，節點故障在分佈式系統下是比較常見的問題，指的是組成服務器集羣的節點會出現的宕機或「僵死」的現象，這種現象常常會發生。

 

1.1.2.1.2. CAP理論

前面花費了很大的篇幅來了解分佈式的特色以及會碰到不少會讓人頭疼的問題，這些問題確定會有必定的理論思想來解決問題的。

接下來花點時間來談談這些理論，其中CAP和BASE理論是基礎，也是面試的時候常常會問到的

 

首先看下CAP，CAP其實就是一致性，可用性，分區容錯性這三個詞的縮寫

 

1.1.2.1.2.1. 一致性

一致性是事務ACID的一個特性【原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）】，學習數據庫優化的時候deer老師講過。

 

這裏講的一致性其實大同小異，只是如今考慮的是分佈式環境中，仍是不單一的數據庫。

 

在分佈式系統中，一致性是數據在多個副本之間是否可以保證一致的特性，這裏說的一致性和前面說的對等性其實差很少。若是可以在分佈式系統中針對某一個數據項的變動成功執行後，全部用戶均可以立刻讀取到最新的值，那麼這樣的系統就被認爲具備【強一致性】。

 

1.1.2.1.2.2. 可用性

可用性指系統提供服務必須一直處於可用狀態，對於用戶的操做請求老是可以在有限的時間內訪問結果。

這裏的重點是【有限的時間】和【返回結果】

爲了作到有限的時間須要用到緩存，須要用到負載，這個時候服務器增長的節點是爲性能考慮；

爲了返回結果，須要考慮服務器主備，當主節點出現問題的時候須要備份的節點能最快的頂替上來，千萬不能出現OutOfMemory或者其餘500，404錯誤，不然這樣的系統咱們會認爲是不可用的。

1.1.2.1.2.3. 分區容錯性

分佈式系統在遇到任何網絡分區故障的時候，仍然須要可以對外提供知足一致性和可用性的服務，除非是整個網絡環境都發生了故障。

不能出現腦裂的狀況

 

 

 

1.1.2.1.2.4. 具體描述

來看下CAP理論具體描述：

一個分佈式系統不可能同時知足一致性、可用性和分區容錯性這三個基本需求，最多隻能同時知足其中的兩項

 

 

 

TIPS：不可能把全部應用所有放到一個節點上，所以架構師的精力每每就花在怎麼樣根據業務場景在A和C直接尋求平衡；

1.1.2.1.3. BASE理論

根據前面的CAP理論，架構師應該從一致性和可用性之間找平衡，系統短期徹底不可用確定是不容許的，那麼根據CAP理論，在分佈式環境下必然也沒法作到強一致性。

 

BASE理論：即便沒法作到強一致性，但分佈式系統能夠根據本身的業務特色，採用適當的方式來使系統達到最終的一致性；

 

1.1.2.1.3.1. Basically Avaliable  基本可用

當分佈式系統出現不可預見的故障時，容許損失部分可用性，保障系統的「基本可用」；體如今「時間上的損失」和「功能上的損失」；

e.g：部分用戶雙十一高峯期淘寶頁面卡頓或降級處理；

 

1.1.2.1.3.2. Soft state 軟狀態

其實就是前面講到的三態,既容許系統中的數據存在中間狀態，既系統的不一樣節點的數據副本之間的數據同步過程存在延時，並認爲這種延時不會影響系統可用性；

e.g：12306網站賣火車票，請求會進入排隊隊列；

1.1.2.1.3.3. Eventually consistent 最終一致性

全部的數據在通過一段時間的數據同步後，最終可以達到一個一致的狀態；

e.g：理財產品首頁充值總金額短時不一致；

 

1.2. Zookeeper簡介

1.2.1. Zookeeper簡介（what）

ZooKeeper致力於提供一個高性能、高可用，且具有嚴格的順序訪問控制能力的分佈式協調服務，是雅虎公司建立，是Google的Chubby一個開源的實現，也是Hadoop和Hbase的重要組件。

 

1.2.1.1. 設計目標

l 簡單的數據結構：共享的樹形結構，相似文件系統，存儲於內存；

l 能夠構建集羣：避免單點故障，3-5臺機器就能夠組成集羣，超過半數正常工做就能對外提供服務；

l 順序訪問：對於每一個讀請求，zk會分配一個全局惟一的遞增編號，利用這個特性能夠實現高級協調服務；

l 高性能：基於內存操做，服務於非事務請求，適用於讀操做爲主的業務場景。3臺zk集羣能達到13w QPS；

 

1.2.2. 哪些常見須要用到ZK（why）

數據發佈訂閱

負載均衡

命名服務

Master選舉

集羣管理

配置管理

分佈式隊列

分佈式鎖

 

1.2.3. 爲何要學習zookeeper？（why）

互聯網架構師必備技能

高端崗位必考察的知識點

zk面試問題全解析

l Zookeeper是什麼框架

l 應用場景

l Paxos算法& Zookeeper使用協議

l 選舉算法和流程

l Zookeeper有哪幾種節點類型

l Zookeeper對節點的watch監聽通知是永久的嗎？

l 部署方式？集羣中的機器角色都有哪些？集羣最少要幾臺機器

l 集羣若是有3臺機器，掛掉一臺集羣還能工做嗎？掛掉兩臺呢？

l 集羣支持動態添加機器嗎？