A. zk是內存存儲還是磁碟
據我了解是磁碟存儲，一級緩存在內存
B. Zookeeper深入原理
Zookeeper 的視圖結構是一個樹形結構，樹上的每個節點稱之為數據節點（即 ZNode），每個ZNode 上都可以保存數據，同時還可以掛載子節點。並且Zookeeper的根節點為 "/"。
在 Zookeeper 中，每個數據節點都是有生命周期的，其生命周期的長短取決於數據節點的節點類型。在 Zookeeper 中有如下幾類節點：
每個數據節點中除了存儲了數據內容之外，還存儲了數據節點本身的一些狀態信息（State）。
在Zookeeper 中，事務是指能夠改變 Zookeeper 伺服器狀態的操作，我們也稱之為事務操作或更新操作，一般包括數據節點創建與刪除、數據節點內容更新和客戶端會話創建與失效等操作。對於每一個事務請求，Zookeeper 都會為其分配一個全局唯一的事務ID，用 ZXID 來表示，通常是一個 64 位的數字。每一個 ZXID 對應一次更新操作，從這些 ZXID 中可以間接地識別出 Zookeeper 處理這些更新操作請求的全局順序。
ZXID 是一個 64 位的數字，其中低 32 位可以看作是一個簡單的單調遞增的計數器，針對客戶端的每一個事務請求，Leader 伺服器在產生一個新的事務 Proposal 的時候，都會對該計數器進行加 1 操作；而高 32 位則代表了 Leader 周期 epoch 的編號，每當選舉產生一個新的 Leader 伺服器，就會從這個 Leader 伺服器上取出其本地日誌中最大事務 Proposal 的 ZXID，並從該 ZXID 中解析出對應的 epoch 值，然後再對其進行加 1 操作，之後就會以此編號作為新的 epoch，並將低 32 位置 0 來開始生成新的 ZXID。
Zookeeper 中為數據節點引入了版本的概念，每個數據節點都具有三種類型的版本信息（在上面的狀態信息中已經介紹了三種版本信息代表的意思），對數據節點的任何更新操作都會引起版本號的變化。其中我們以 dataVersion 為例來說明。在一個數據節點被創建完畢之後，節點的dataVersion 值是 0，表示的含義是 」當前節點自從創建之後，被更新過 0 次「。如果現在對該節點的數據內容進行更新操作，那麼隨後，dataVersion 的值就會變成 1。即表示的是對數據節點的數據內容的變更次數。
版本的作用是用來實現樂觀鎖機制中的 「寫入校驗」 的。例如，當要修改數據節點的數據內容時，帶上版本號，如果數據節點的版本號與傳入的版本號相等，就進行修改，否則修改失敗。
Zookeeper 提供了分布式數據的發布/訂閱功能。一個典型的發布/訂閱模型系統定義了一種一對多的訂閱關系，能夠讓多個訂閱者同時監聽某一個主題對象，當這個主題對象自身狀態變化時，會通知所有訂閱者，使它們能夠做出相應的處理。在 Zookeeper 中，引入了 Watcher 機制來實現這種分布式的通知功能。Zookeeper 允許客戶端向服務端注冊一個 Watcher 監聽，當服務端的一些指定事件觸發了這個 Watcher，那麼就會向指定客戶端發送一個事件通知來實現分布式的通知功能。
從上圖可以看出 Zookeeper 的 Watcher 機制主要包括客戶端線程、客戶端WatchMananger 和 Zookeeper 伺服器三部分。在具體工作流程上，簡單地講，客戶端在向 Zookeeper 伺服器注冊 Watcher 的同時，會將 Watcher 對象存儲在客戶端的 WatchMananger 中。當 Zookeeper 伺服器端觸發 Watcher 事件後，會向客戶端發送通知，客戶端線程從 WatchManager 中取出對應的 Watcher 對象來執行回調邏輯。
Watcher是一個介面，任何實現了Watcher介面的類就是一個新的Watcher。Watcher內部包含了兩個枚舉類：KeeperState、EventType
注 ：客戶端接收到的相關事件通知中只包含狀態及類型等信息，不包括節點變化前後的具體內容，變化前的數據需業務自身存儲，變化後的數據需調用get等方法重新獲取；
上面講到zookeeper客戶端連接的狀態和zookeeper對znode節點監聽的事件類型，下面我們來講解如何建立zookeeper的watcher監聽。在zookeeper中採用zk.getChildren(path, watch)、zk.exists(path, watch)、zk.getData(path, watcher, stat)這樣的方式為某個znode注冊監聽。
下表以node-x節點為例，說明調用的注冊方法和可監聽事件間的關系：
Zookeeper 中提供了一套完善的 ACL（Access Control List）許可權控制機制來保障數據的安全。
ACL 由三部分組成，分別是：許可權模式（Scheme）、授權對象（ID）和許可權（Permission），通常使用「scheme: id:permission」來標識一個有效的ACL 信息。下面分別介紹：
1.7.4、ACL 超級管理員
zookeeper的許可權管理模式有一種叫做super，該模式提供一個超管可以方便的訪問任何許可權的節點
假設這個超管是：super:admin，需要先為超管生成密碼的密文
那麼打開zookeeper目錄下的/bin/zkServer.sh伺服器腳本文件，找到如下一行：
這就是腳本中啟動zookeeper的命令，默認只有以上兩個配置項，我們需要加一個超管的配置項
那麼修改以後這條完整命令變成了
之後啟動zookeeper,輸入如下命令添加許可權
在伺服器集群初始化階段，我們以 3 台機器組成的伺服器集群為例，當有一台伺服器server1 啟動的時候，它是無法進行 Leader 選舉的，當第二台機器 server2 也啟動時，此時這兩台伺服器已經能夠進行互相通信，每台機器都試圖找到一個 Leader，於是便進入了 Leader 選舉流程。
在zookeeper運行期間，leader與非leader伺服器各司其職，即便當有非leader伺服器宕機或新加入，此時也不會影響leader，但是一旦leader伺服器掛了，那麼整個集群將暫停對外服務，進入新一輪leader選舉，其過程和啟動時期的Leader選舉過程基本一致。
假設正在運行的有server1、server2、server3三台伺服器，當前leader是server2，若某一時刻leader掛了，此時便開始Leader選舉。選舉過程如下:
observer角色特點：
為了使用observer角色，在任何想變成observer角色的配置文件中加入如下配置：
並在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：
C. 如何提高zookeeper每個結點所能存儲的數據大小
今天發現一個問題，zookeeper默認對每個結點的最大數據量有一個上限是1M，如果你要設置的配置數據大於這個上限將無法寫法，在網上查了一圈發現有一個解決方案如下，增加-Djute.maxbuffer=10240000參數
最終提供一個完整的修改後的zkServer.sh文件如下
#!/bin/sh
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding right ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# If this scripted is run out of /usr/bin or some other system bin directory
# it should be linked to and not copied. Things like java jar files are found
# relative to the canonical path of this script.
#
# See the following page for extensive details on setting
# up the JVM to accept JMX remote management:
# http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html
# by default we allow local JMX connections
ZOO_USER_CFG="-Djute.maxbuffer=10240000"
if [ "x$JMXLOCALONLY" = "x" ]
then
JMXLOCALONLY=false
fi
if [ "x$JMXDISABLE" = "x" ]
then
echo "JMX enabled by default" >&2
# for some reason these two options are necessary on jdk6 on Ubuntu
# accord to the docs they are not necessary, but otw jconsole cannot
# do a local attach
ZOOMAIN="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=$JMXLOCALONLY org.apache.zookeeper.server.quorum.QuorumPeerMain"
else
echo "JMX disabled by user request" >&2
ZOOMAIN="org.apache.zookeeper.server.quorum.QuorumPeerMain"
fi
# Only follow symlinks if readlink supports it
if readlink -f "$0" > /dev/null 2>&1
then
ZOOBIN=`readlink -f "$0"`
else
ZOOBIN="$0"
fi
ZOOBINDIR=`dirname "$ZOOBIN"`
. "$ZOOBINDIR"/zkEnv.sh
if [ "x$SERVER_JVMFLAGS" ]
then
JVMFLAGS="$SERVER_JVMFLAGS $JVMFLAGS"
fi
if [ "x$2" != "x" ]
then
ZOOCFG="$ZOOCFGDIR/$2"
fi
# if we give a more complicated path to the config, don't screw around in $ZOOCFGDIR
if [ "x`dirname $ZOOCFG`" != "x$ZOOCFGDIR" ]
then
ZOOCFG="$2"
echo "Using config:$2" >&2
fi
if $cygwin
then
ZOOCFG=`cygpath -wp "$ZOOCFG"`
# cygwin has a "kill" in the shell itself, gets confused
KILL=/bin/kill
else
KILL=kill
fi
echo "Using config: $ZOOCFG" >&2
if [ -z $ZOOPIDFILE ]
then ZOOPIDFILE=$(grep dataDir "$ZOOCFG" | sed -e 's/.*=//')/zookeeper_server.pid
fi
_ZOO_DAEMON_OUT="$ZOO_LOG_DIR/zookeeper.out"
case $1 in
start)
echo -n "Starting zookeeper ... "
if [ -f $ZOOPIDFILE ]; then
if kill -0 `cat $ZOOPIDFILE` > /dev/null 2>&1; then
echo $command already running as process `cat $ZOOPIDFILE`.
exit 0
fi
fi
nohup $JAVA "$ZOO_USER_CFG" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &
if [ $? -eq 0 ]
then
if /bin/echo -n $! > "$ZOOPIDFILE"
then
sleep 1
echo STARTED
else
echo FAILED TO WRITE PID
exit 1
fi
else
echo SERVER DID NOT START
exit 1
fi
;;
start-foreground)
ZOO_CMD="exec $JAVA"
if [ "${ZOO_NOEXEC}" != "" ]; then
ZOO_CMD="$JAVA"
fi
$ZOO_CMD "$ZOO_USER_CFG" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG"
;;
print-cmd)
echo "$JAVA -Dzookeeper.log.dir=\"${ZOO_LOG_DIR}\" -Dzookeeper.root.logger=\"${ZOO_LOG4J_PROP}\" -cp \"$CLASSPATH\" $JVMFLAGS $ZOOMAIN \"$ZOOCFG\" > \"$_ZOO_DAEMON_OUT\" 2>&1 < /dev/null"
;;
stop)
echo -n "Stopping zookeeper ... "
if [ ! -f "$ZOOPIDFILE" ]
then
echo "no zookeeper to stop (could not find file $ZOOPIDFILE)"
else
$KILL -9 $(cat "$ZOOPIDFILE")
rm "$ZOOPIDFILE"
echo STOPPED
fi
;;
upgrade)
shift
echo "upgrading the servers to 3.*"
$JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS org.apache.zookeeper.server.upgrade.UpgradeMain ${@}
echo "Upgrading ... "
;;
restart)
shift
"$0" stop ${@}
sleep 3
"$0" start ${@}
;;
status)
# -q is necessary on some versions of linux where nc returns too quickly, and no stat result is output
STAT=`$JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS org.apache.zookeeper.client.FourLetterWordMain localhost \
$(grep "^[[:space:]]*clientPort" "$ZOOCFG" | sed -e 's/.*=//') srvr 2> /dev/null \
| grep Mode`
if [ "x$STAT" = "x" ]
then
echo "Error contacting service. It is probably not running."
exit 1
else
echo $STAT
exit 0
fi
;;
*)
echo "Usage: $0 {start|start-foreground|stop|restart|status|upgrade|print-cmd}" >&2
esac
D. 什麼是ZK-Rollup（零知識匯總）
ZK-Rollup（零知識匯總）基於zero-knowledge proof（零知識證明），在發往主鏈的交易包里包含了一個對應的零知識證明，主鏈上的rollup（匯總）智能合約只需驗證這個零知識證明。
這個零知識證明不會透露任何交易細節，但能通過與智能合約不斷交互，證明上鏈的所有數據的有效性和真實性。
優點：
l高度的去中心化
l隱私性好：零知識證明不會透露任何交易細節
l上鏈效率高：一次性提交多筆操作的結果，節約時間和gas fee
l驗證效率高：無需等待期，快速完成資產取出動作
l安全性極高：zk技術保證了提交給主鏈的數據真實有效，同時主鏈可隨時還原側鏈發生的交易細節（即擁有主鏈的數據可用性），因此擁有以太坊級別的安全性
缺點：
l技術開發難度大
l難兼容不同智能合約
l需要大量運算
代表項目：
l路印：成熟的zk技術運用，獲得4500萬美元私募，當前市值超8億美元
lZKSync：旨在為以太坊帶來 Visa 級別、每秒數千筆交易的吞吐量
鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。
E. zkparking資料庫配置程序
摘要 這邊給您查詢分析到每台機器的應用程序都需要連接資料庫，而資料庫的配置信息（連接信息），這時候放在機器本地的話不方面（機器多，需要一個個改配置信息），這就用到Zookeeper，把資料庫的配置信息放到配置中心，利用Zookeeper節點可以存儲數據的特性，然後各台機器可以使用JavaAPI去獲取Zookeeper中資料庫的配置信息。每一個應用都在Zookeeper節點注冊監聽器，一旦節點信息改變，各台機器就獲取信息，使用最新的信息連接資料庫，這樣優點一是方便了管理（只放置一份數據在配置中心，沒必要放到多個機器上去），二是一旦配置改了，就做一個發布的動作即可。
F. zkteco考勤機使用方法是什麼
使用方法：
1、首先要確保考勤機和安裝了ZKTeco軟體的PC在同一網段。然後打開考勤軟體。選中我們的設備（如果有多個設備，在右邊可以看到設備編號的），選中「連接設備」。
2、右下角連接成功後，在左側選擇「從設備下載記錄數據」，把設備上的最新數據下載到本地pc上面來。下載完畢後，其實就可以斷開連接了，後面的操作本地都可以進行了。
考勤機分兩大類：
第一類是簡單列印類，打卡時，原始記錄數據通過考勤機直接列印在卡片上，卡片上的記錄時間極為原始的考勤信息，對初次使用者無需做任何事先的培訓即可立即使用。
第二類是存儲類，打卡時，原始記錄數據直接存儲在考勤機內，然後通過計算機採集匯總，再通過軟體處理，最後形成所需的考勤信息或查詢或列印，其考勤信息靈活豐富，對初次使用者需做一些事先培訓才能逐漸掌握其全部使用功能。
G. zookeeper
客戶端的Watcher
String就是節點的path，有三大類。
dataWatches：數據watcher
existWatches：節點是否存在的watcher
childWatches：節點的子節點個數變化，包括：0->1，1->2等等，只要數量變化就觸發。
對於zk的watcher機制，有幾個疑問？
三、ZK的通信協議
分兩類：請求和響應協議。是基於TCP/IP的應用層協議，其實就是規定了應用層報文的格式，以及每個欄位的含義。客戶端和服務端雙方都遵守這種約定，脫離了ZK，其他框架是無法識別這種通信協議的。
請求和響應報文格式，網上搜一下一大堆。這里不再贅述
那麼回到什麼是分布式協調呢？我們就以RPC這種場景來說：
比如我們可以理解上面的圖，一半client是service角色，一半client是consumer角色，然後zk提供了這些client之間的協調 -- 充當consumer角色的client必須依賴於充當service角色提供的服務，這可不就是分布式協調的一種嘛（協調其中一半的client依賴另一半）。當然我們可以繼續擴展：分布式配置中心Disconf，有個client它的角色可以是管理員(配置員)，它是一個進程。它向zk某一個節點配置了XX數據，然後其他所有client同時收到最新配置。這可不就是另外一種協調了嘛（其他client依賴這個配置的值執行業務）。
ZooKeeper 是一個典型的分布式數據一致性解決方案，分布式應用程序可以基於 ZooKeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能
乍一看這個定義挺抽象的，一時半會沒理解。其實舉個例子就容易理解的多，比如你有個資源，我們先簡單把該資源當做一個本地文件或本地電影。你為了保證該資源的可靠性，你需要把該資源到3台機器上。那麼這三個資源，在互聯網上就會有三個url地址：機器1/xxx/xxx/xxx.pdf，機器2/xxx/xxx/xxx.pdf，機器3/xxx/xxx/xxx.pdf。請求方為了訪問該資源，肯定不會把這三個地址硬編碼到自己本地，這樣不易拓展。所以這個時候，就需要一個統一命名服務來封裝該資源的三個真實地址，對外只提供一個地址並且永遠可以不變。那麼這個統一命名服務，我們當然可以用http協議來實現，也可以用zk協議(ZAB協議)來實現。
現在理解了上面的內容，那麼我們就容易拓展這個資源的定義了。上面所說的資源，我們可以拓展為一個服務 xxx.xxx.xxx.UserService，該服務的提供方可以有很多個，但是為了封裝真實提供方，我們只能對外暴露一個地址那就是xxx.xxx.xxx.UserService。是不是很熟悉？Dubbo的ZK注冊中心，就是這么乾的。
理解定義我們就不說了，這個很好理解。實際案例咱們可以參考Dubbo的ZK，提供者發布或修改服務真實地址後，消費者可以實時收到變化的通知，然後再去ZK拉取最新數據。這可不就是ZK的發布與訂閱嘛，通過Listener觀察者模式來實現。應用場景很多：RPC服務發現，配置中心的配置分發等等。
所謂集群管理無在乎兩點：是否有機器退出和加入、選舉 Master。
不就是ZK的發布訂閱嘛，沒啥好說的。
這里的maser選舉，可不是ZK內部的master選舉（兩者相差十萬八千里）。這里的master選舉，是指業務調用方，屬於client角色的進程，進行選舉。
業務master選舉其實很簡單，完全沒必要像ZK內部選舉那樣，還要實現一套可靠的選舉演算法(paxos演算法包含了一個提案選舉，paxos演算法可不止一個選舉演算法)。ZK本身提供了一個可靠創建唯一節點的API介面，這個介面保證了並發調用只會有一個成功。那麼業務master選舉，是不是可以轉化為多個業務進程並發調用該API介面，誰創建唯一節點成功了，誰就是master了，其他進程就是slave。怎麼感覺這么像分布式鎖的實現呢？除了少了釋放鎖的通知操作。。。
軟負載均衡也沒啥好說的，就是注冊與發現的變種，或者說發布與訂閱的變種。獲取統一命名服務的所有提供者列表，然後通過負載均衡演算法在這一堆列表中選擇一個，策略可以是隨機選擇，輪訓選擇，Hash一致性選擇等等。。。Dubbo的負債均衡是實現在消費者調用邏輯裡面的，並不在獲取列表介面裡面，ZK不做負載均衡，基於ZK的應用可以做。
和上面的數據發布與訂閱 一模一樣 ，不在贅述。
和上面說的Master選舉很像，都是一堆client角色的業務調用方，調用創建某唯一節點的API。誰創建成功，誰就拿鎖。只不過ZK的底層實現是嚴格按照順序來的，所以必然是ZK接收請求的時候，誰第一個誰拿鎖。注意可不是client誰先請求誰拿鎖。client請求還要經過網路，同時請求是沒法確定哪個client先到達的。
但是光創建唯一節點成功還不叫鎖，鎖天然包含了兩個功能：可重入和釋放鎖喚醒其他等待的client節點。可重入ZK是實現不了，需要業務方自己實現。釋放鎖的喚醒ZK是通過Listener的通知喚醒的。
我們看下上面的所有應用場景，其實本質上都是調用zk的兩個最核心的介面：創建節點和監聽節點變化。
ZooKeeper 將數據保存在內存中，這也就保證了高吞吐量和低延遲 （但是內存限制了能夠存儲的容量不太大，此限制也是保持 znode 中存儲的數據量較小的進一步原因）。ZK集群加機器可不能增加內存，為啥呢？因為ZK集群裡面的所有數據，都是每台機器保存一份副本。整個集群內存最小的機器，決定整個集群的內存大小。
ZooKeeper 是高性能的。在「讀」多於「寫」的應用程序中尤其的高性能 ，因為「寫」會導致所有的伺服器間同步狀態。（「讀」多於「寫」是協調服務的典型場景。）
ZooKeeper 底層其實只提供了兩個功能：
H. 如何查看zookeeper安裝路徑
然後每個文件夾裡面解壓一個zookeeper的下載包，並且還建了幾個文件夾，總體結構如下,最後那個是下載過來壓縮包的解壓文件
data dataLog logs zookeeper-3.3.2
那麼首先進入data目錄，創建一個myid的文件，裡面寫入一個數字，比如我這個是server1,那麼就寫一個1，server2對應myid文件就寫入2，server3對應myid文件就寫個3
然後進入zookeeper-3.3.2/conf目錄，那麼如果是剛下過來，會有3個文件，configuration.xml, log4j.properties,zoo_sample.cfg,這3個文件我們首先要做的就是在這個目錄創建一個zoo.cfg的配置文件，當然你可以把zoo_sample.cfg文件改成zoo.cfg，配置的內容如下所示：
tickTime=2000
initLimit=5
syncLimit=2
dataDir=xxxx/zookeeper/server1/data
dataLogDir=xxx/zookeeper/server1/dataLog
clientPort=2181
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890
標紅的幾個配置應該官網講得很清楚了，只是需要注意的是clientPort這個埠如果你是在1台機器上部署多個server,那麼每台機器都要不同的clientPort，比如我server1是2181,server2是2182，server3是2183，dataDir和dataLogDir也需要區分下。
最後幾行唯一需要注意的地方就是 server.X 這個數字就是對應 data/myid中的數字。你在3個server的myid文件中分別寫入了1，2，3，那麼每個server中的zoo.cfg都配server.1,server.2,server.3就OK了。因為在同一台機器上，後面連著的2個埠3個server都不要一樣，否則埠沖突，其中第一個埠用來集群成員的信息交換，第二個埠是在leader掛掉時專門用來進行選舉leader所用。
進入zookeeper-3.3.2/bin 目錄中，./zkServer.sh start啟動一個server,這時會報大量錯誤？其實沒什麼關系，因為現在集群只起了1台server，zookeeper伺服器端起來會根據zoo.cfg的伺服器列表發起選舉leader的請求，因為連不上其他機器而報錯，那麼當我們起第二個zookeeper實例後，leader將會被選出，從而一致性服務開始可以使用，這是因為3台機器只要有2台可用就可以選出leader並且對外提供服務(2n+1台機器，可以容n台機器掛掉)。
接下來就可以使用了，我們可以先通過 zookeeper自帶的客戶端交互程序來簡單感受下zookeeper到底做一些什麼事情。進入zookeeper-3.3.2/bin（3個server中任意一個）下，./zkCli.sh –server 127.0.0.1:2182,我連的是開著2182埠的機器。
那麼，首先我們隨便打個命令，因為zookeeper不認識，他會給出命令的help,如下圖
ls(查看當前節點數據),
ls2(查看當前節點數據並能看到更新次數等數據) ,
create(創建一個節點) ,
get(得到一個節點，包含數據和更新次數等數據),
set(修改節點)
delete(刪除一個節點)
通過上述命令實踐，我們可以發現，zookeeper使用了一個類似文件系統的樹結構，數據可以掛在某個節點上，可以對這個節點進行刪改。另外我們還發現，當改動一個節點的時候，集群中活著的機器都會更新到一致的數據。
I. zookeeper在配置偽集群模式時，myid文件是什麼，什麼格式
myid的值是zoo.cfg文件里定義的server.A項A的值。Zookeeper啟動時會讀取這個文件。解決方法如下：
1、首先獲取zookeeper安裝包，zookeeper包的獲取可以直接到Apache的網站獲取。