從0開始的高併發(一)--- Zookeeper的基礎概念

前言

前面幾篇以spring做爲主題也是有些時日了,高併發分佈式這個主題也挺大能說挺多東西的,也是再開了個坑,而後分P來慢慢跟進吧。 我和大部分人同樣是一名學習者,不是佈道者,更多的是本身的學習總結而不具備權威,進行總結,儘可能讓人看的簡單是個人本意,而後有錯則改,無則加勉是最好的,在此也但願你們共同進步。java

高併發分佈式開發技術體系已然很是的龐大,從國內互聯網企業使用狀況,可發現RPC、Dubbo、ZK是最基礎的技能要求。 關於Zookeeper你是否是還停留在Dubbo註冊中心的印象中呢?還有它的工做原理呢?經典應用場景呢?對前面三個問題,如若回答時沒有本身的思路或者說並未瞭解,那麼我以爲我能夠幫助到你去入門,並深化這些知識,讓你在面試中更好地去回答。node

話很少說進入正題

1. 併發環境下面臨的挑戰

回憶咱們學多線程的時候,網上有個圖也是十分的有意思linux

其實咱們把線程換成進程,至關於每臺服務上跑了一個程序,相同的應用程序運行於多個服務器集羣上,是爲了解決單臺服務面對高併發處理不來的狀況。而嘗試去處理這些狀況,咱們就會面臨不少諸如此類的問題面試

好比說咱們如今是3臺服務器的一個集羣, 怎麼保證全部機器共享的配置信息保持一致?spring

有一臺機器掛掉了,其餘機器如何感知到這一變化並接管任務?apache

用戶量忽然的爆增,須要增長機器來緩解壓力,如何作到不重啓集羣而完成機器的添加?tomcat

分佈式系統,怎麼高效協同多臺服務對同一網絡文件進行寫操做(網絡並非即時的,它並不可靠,存在延時)?服務器

此時咱們就須要一個相似於線程協同機制的能讓進程進行協同的工具網絡

2. Zookeeper的介紹

① Zookeeper的名字由來

在apache上的許多開源項目都是以動物形象做爲icon,好比tomcat就是一隻貓,hive是隻黃蜂等,zookeeper的工做就是把這些動物的行動進行協調session

② Zookeeper的簡介

zookeeper就是一種用於分佈式應用程序的高性能協調服務,它的特色就是數據是存於內存中的,持久化實如今日誌中。它的內存相似於樹形結構,且高吞吐低延遲,能夠幫助咱們實現分佈式統一配置中心,服務註冊,分佈式鎖等 組成ZooKeeper服務的服務器必須彼此瞭解。它們維護內存中的狀態圖像,以及持久性存儲中的事務日誌和快照。只要大多數服務器可用,ZooKeeper服務就可用。客戶端鏈接到單個ZooKeeper服務器。客戶端維護TCP鏈接,經過該鏈接發送請求,獲取響應,獲取監視事件以及發送tick。若是與服務器的TCP鏈接中斷,則客戶端將鏈接到其餘服務器。

③ Zookeeper的安裝(linux下)

1.JDK版本須要在1.6以上
2.下載: https://archive.apache.org/dist/zookeeper/zookeeper-3.5.2/zookeeper-3.5.2.tar.gz
3.解壓後的conf目錄,增長配置文件zoo.cfg
4.啓動服務端 bin/zkServer.sh start
5.測試,客戶端鏈接: bin/zkCli.sh -server 127.0.0.1:2181
zoo.cfg的關鍵配置有3個:
    tickTime=2000:一次心跳的基本時間,
    dataDir:數據與日誌的存放處
    clientPort:端口號
複製代碼

④ Zookeeper的特色

1.數據結構簡單

相似於Unix文件系統樹形結構,每一個目錄成爲Znode節點,但它不一樣於文件系統,它既能夠視爲文件夾,也能夠視爲文件來存放數據,可是咱們平時仍是得叫它節點,別叫文件夾這麼掉價。

須要注意:同一個節點下的子節點名稱不能相同,且命名是有規範的,它的路徑是沒有相對路徑的概念的,都是絕對路徑,任何開始都以"/"開始,最後就是,它存放數據的大小是有限制的

2.數據模型特色

層次命名空間:就是上面已經提到的,相似於unix的文件系統,以"/"爲根,節點能夠包含關聯數據和子節點,絕對路徑 Znode:名稱惟一,命名有規範,類型分4種:持久,順序,臨時,臨時順序,節點的數據構成以後再提

3.命名規範

節點名稱除下列限制外,可使用任何unicode字符:

1. null字符(\u0000)不能做爲路徑名的一部分;

2. 如下字符不能使用,由於它們不能很好地顯示,或者以使人困惑的方式呈現:\u0001 - \u0019和\u007F - \u009F。

3. 不容許使用如下字符:\ud800 - uf8fff, \uFFF0 - uFFFF。

4. 「.」字符能夠用做另外一個名稱的一部分,可是「.」和「..」不能單獨用於指示路徑上的節點,由於ZooKeeper不使用相對路徑。

下列內容無效:「/a/b/. / c」或「c / a / b / . . /」。

5. 「zookeeper」是保留節點名。
複製代碼
4.一些命令

由於個人電腦是window系統的,因此我找了一個window版本的zookeeper來進行演示

先大體解釋一下各個目錄的內容

bin ---> 包括了linux和window的運行程序的運行目錄
conf ---> zookeeper的配置zoo.cfg
contrib ---> 其餘一些組件和發行版本
dist-maven ---> maven發佈下的一些jar包
docs ---> 文檔
lib ---> 庫
recipe ---> 一些應用實例
src ---> zookeeper的源碼,由於zookeeper是java寫出來的
複製代碼

啓動bin目錄下的zkServer.cmd,再啓動zkClient.cmd便可,在我根本不知道該如何進行學習的時候,通常來講輸入help,-help,-h這些指令就能夠獲取到幫助,下圖我就是在客戶端輸入了-help指令

由於命令都相對簡單因此也不進行演示了,惟一須要注意的是要注意路徑"/"的問題,好比 ls / 就是根目錄,create /zk 123,還有各個命令的依託條件,好比create必需要提供父節點,delete節點時次節點不能有子節點等···

5.Zookeeper的重要特色---有序

提供多種方式跟蹤時間,ZooKeeper給每一個更新貼上一個數字,這個數字反映了全部ZooKeeper事務的順序,嚴格的順序意味着能夠在客戶機上實現複雜的同步原語 解釋czxid、version、zoo.cfg中ticks配置

  • Zxid :Zookeeper中每次寫請求都對應一個惟一的事務id,稱爲 Zxid,它是全局的且有序的,若是 Zxid1 小於 Zxid2,那 Zxid1 就必定是發生在 Zxid2 前
  • version numbers : 版本號,對節點的寫請求都會致使該節點的3種版本號增長(其實套路和樂觀鎖差很少),dataVersion(對znode數據的更改次數),cversion(對znode子節點的更改次數),aclVersion(對znode ACL的更改次數
  • ticks : 當使用多服務器Zookeeper時,服務器使用一個「滴答」來定義事件的時間,如狀態上傳,會話超時等,它經過最小會話超時(默認是滴答時間x2)間接公開,若是客戶端請求超過這個時間,那客戶端就再也不能鏈接上服務器端
  • real time:Zookeeper並不使用真實時間

你可使用stat path或者ls2來查看這些信息

cZxid:建立該節點的zxid
ctime:該節點的建立時間
mZxid:該節點的最後修改zxid
mtime:該節點的最後修改時間
pZxid:該節點的最後子節點修改zxid
cversion:該節點的子節點變動次數
dataVersion:該節點數據被修改的次數
aclVersion:該節點的ACL變動次數
aphemeraOwner:臨時節點全部者會話id,非臨時的爲0
dataLength:該節點數據長度
numChildren:子節點數
複製代碼

這些數據都在從側面告訴咱們,zookeeper是一個協調者

6.zookeeper的第二個特色---可複製

數據可複製,可備份。zookeeper能夠快速地搭建一個集羣,內部自帶了這樣的一些工具與機制,咱們只須要設置一些配置便可,保證服務可靠,不會成爲單點故障

7.zookeeper的第三個特色---迅速

zookeeper的一些特色能夠應用於大型分佈式系統

3.zookeeper的理論

① zookeeper的會話機制

Session會話

1.一個客戶端鏈接一個會話,由zookeeper分配惟一會話id
2.客戶端以特定的時間間隔發送心跳以保持會話有效,
3.超過會話超時時間未收到客戶端的心跳,則判斷客戶端無效(默認2倍tickTime)
4.會話中額請求是FIFO(先進先出原則)的順序執行
複製代碼

② znode的數據構成

節點數據:存儲的基本信息(狀態,配置,位置等)
節點元數據:stat命令下的一些數據
數據大小:限制1M
複製代碼

③ znode的節點類型

1.持久節點:直接經過create path value所建立
2.臨時節點:create -e path value
3.順序節點:create -s path value

注意
    1.session會話失效時,臨時節點就會被刪除
    2.順序節點的建立,後爲10位十進制序號,每一個父節點擁有一個計數器,這個計數器也是有限制的,到2147483647以後將溢出
    3.順序節點在會話結束仍然存在
複製代碼

④ Watch監聽機制

客戶端能在znodes上設置watch,監聽znode的變化,包括增刪改查,經過stat path ,ls2 path get path皆可查看

觸發watch事件的條件有4種,create,delete,change,child(子節點事件)

watch的重要特性

1.僅一次性:watch觸發後會當即刪除,要持續監聽變化的話就要持續提供設置watch,這也是watch的注意事項

2.有序性:客戶端先獲得watch通知纔可查看變化結果
複製代碼

watch的注意事項

1.剛剛說起到的它的僅一次性

2.獲取事件和發送watch,獲取watch,這些請求有可能存在延時,因此不能絕對可靠獲得每一個節點發生的每一個更改

3.一個watch對象只會被通知一次,若是一個watch同時註冊了多個接口(exists,getData),若是此時刪除節點,雖然這個事件對exists和getData都有效,可是watch只會被調用一次
複製代碼

阻塞線程喚醒機制—客戶端能夠被動接受其餘客戶端進程狀態通知

⑤ zookeeper的特性

1.順序一致性(Sequential Consistency),保證客戶端操做是按順序生效的;

 2.原子性(Atomicity),更新成功或失敗。沒有部分結果。 

 3.單個系統映像,不管鏈接到哪一個服務器,客戶端都將看到相同的內容

 4.可靠性,數據的變動不會丟失,除非被客戶端覆蓋修改。

 5.及時性,保證系統的客戶端當時讀取到的數據是最新的。
複製代碼

finally

經過上面的闡述應該咱們對於zookeeper有了一個初步的認識,以後會陸續說說分佈式鎖,集羣還有一些場景的應用

下一篇:從零開始的高併發(2)---Zookeeper實現分佈式鎖

相關文章
相關標籤/搜索