zookeeper 工作原理：
1 什么是zookeeper
ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務。它是一個為分布式應用提供一致性服務的軟件.
在分布式應用中，由於工程師不能很好地使用鎖機制，以及基於消息的協調機制不適合在某些應用中使用，因此需要有一種可靠的、可擴展的、分布式的、可配置的協調機制來統一系統的狀態。Zookeeper的目的就在於此.
提供的功能包括：配置維護、域名服務、分布式同步、集群管理等。
2 zookeeper 基本概念：
Zookeeper中的角色主要有以下三類，如下表所示
在zookeeper的集群中，各個節點共有下面3種角色和4種狀態：
角色：leader，follower，observer
狀態：leading，following，observing，looking
每個Server在工作過程中有4種狀態：
LOOKING：當前Server不知道leader是誰，正在搜尋。
LEADING：當前Server即為選舉出來的leader。
FOLLOWING：leader已經選舉出來，當前Server與之同步。
OBSERVING：observer的行為在大多數情況下與follower完全一致，但是他們不參加選舉和投票，
而僅僅接受(observing)選舉和投票的結果
zookeeper Leader選舉
Leader選舉有如下兩種
第一種：服務器初始化啟動的Leader選舉。
第二種：服務器運行時期的Leader選舉（服務器運行期間無法和Leader保持連接）。
Leader選舉的前提條件
只有服務器狀態在LOOKING（競選狀態）狀態才會去執行選舉算法
Zookeeper 的集群規模至少是2台機器，才可以選舉Leader，這里以3台機器集群為例。
當一台服務器啟動是不能選舉的，等第二台服務器啟動后，兩台機器之間可以互相通信，才可以進行Leader選舉
服務器運行期間無法和Leader保持連接的時候。
服務器啟動時期的 Leader 選舉
在集群初始化階段，當有一台服務器Server1啟動時，其單獨無法進行和完成Leader選舉，當第二台服務器Server2啟動后，
此時兩台機器可以相互通信，每台機器都試圖找到Leader，於是進入Leader選舉過程。選舉過程如下：
(1) 每個Server發出一個投票投給自己。由於是初始情況，Server1和Server2都會將自己作為Leader服務器來進行投票，每次投票會包含所推舉的服務器的myid和ZXID，
使用(myid, ZXID)來表示，此時Server1的投票為(1, 0)，Server2的投票為(2, 0)，然后各自將這個投票發給集群中其他機器。
(2) 接受來自各個服務器的投票。集群的每個服務器收到投票后，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的服務器。
(3) 處理投票。針對每一個投票，服務器都需要將別人的投票和自己的投票進行PK，PK規則如下
1、優先檢查ZXID。ZXID比較大的服務器優先作為Leader。
2、如果ZXID相同，那么就比較myid。myid較大的服務器作為Leader服務器。
對於Server1而言，它的投票是(1, 0)，接收Server2的投票為(2, 0)，首先會比較兩者的ZXID，均為0，再比較myid，此時Server2的myid最大，
於是更新自己的投票為(2, 0)，然后重新投票，對於Server2而言，其無須更新自己的投票，只是再次向集群中所有機器發出上一次投票信息即可。
(4) 統計投票。每次投票后，服務器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server1、Server2而言，
都統計出集群中已經有兩台機器接受了(2, 0)的投票信息，此時便認為已經選出了Leader。
(5) 改變服務器狀態。一旦確定了Leader，每個服務器就會更新自己的狀態，如果是Follower，那么就變更為FOLLOWING，如果是Leader，就變更為LEADING。
服務器運行時期的 Leader 選舉
在Zookeeper運行期間，即便當有非Leader服務器宕機或新加入，此時也不會影響Leader，但是一旦Leader服務器掛了，那么整個集群將暫停對外服務，進入新一輪Leader選舉，
其過程和啟動時期的Leader選舉過程基本一致。假設正在運行的有Server1、Server2、Server3三台服務器，當前Leader是Server2，若某一時刻Leader掛了，此時便開始Leader選舉。選舉過程如下：
(1)變更狀態。Leader掛后，余下的非Observer服務器都會將自己的服務器狀態變更為LOOKING，然后開始進入Leader選舉流程。
(2)每個Server會發出一個投票。在這個過程中，需要生成投票信息(myid,ZXID)每個服務器上的ZXID可能不同，我們假定Server1的ZXID為123，而Server3的ZXID為122；
在第一輪投票中，Server1和Server3都會投自己，產生投票(1, 123)，(3, 122)，然后各自將投票發送給集群中所有機器。
(3)接收來自各個服務器的投票。與啟動時過程相同。
(4)處理投票。與啟動時過程相同，此時，Server1將會成為Leader。
(5)統計投票。與啟動時過程相同。
(6)改變服務器的狀態。與啟動時過程相同。
主流應用場景：
(1)配置管理
集中式的配置管理在應用集群中是非常常見的，一般商業公司內部都會實現一套集中的配置管理中心，應對不同的應用集群對於共享各自配置的需求，並且在配置變更時能夠通知到集群中的每一個機器。
(2)集群管理
應用集群中，我們常常需要讓每一個機器知道集群中（或依賴的其他某一個集群）哪些機器是活着的，並且在集群機器因為宕機，網絡斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器。
另外有一個應用場景就是集群選master,一旦master掛掉能夠馬上能從slave中選出一個master。
KAFKA 工作原理+常用命令
Apache Kafka是分布式發布-訂閱消息系統。Kafka是一種快速、可擴展的、設計內在就是分布式的，分區的和可復制的提交日志服務。
二、Kafka基本架構
它的架構包括以下組件：
1、話題（Topic）：是特定類型的消息流。消息是字節的有效負載（Payload），話題是消息的分類名或種子（Feed）名；
Kafka可以將主題划分為多個分區（Partition），會根據分區規則選擇把消息存儲到哪個分區中，只要如果分區規則設置的合理，那么所有的消息將會被均勻的分布到不同的分區中，
這樣就實現了負載均衡和水平擴展。另外，多個訂閱者可以從一個或者多個分區中同時消費數據，以支撐海量數據處理能力
由於Producer和Consumer都只會與Leader角色的分區副本相連，所以kafka需要以集群的組織形式提供主題下的消息高可用。kafka支持主備復制，所以消息具備高可用和持久性。
一個分區可以有多個副本，這些副本保存在不同的broker上。每個分區的副本中都會有一個作為Leader。當一個broker失敗時，Leader在這台broker上的分區都會變得不可用，
kafka會自動移除Leader，再其他副本中選一個作為新的Leader。
2、生產者（Producer）：是能夠發布消息到話題的任何對象；
3、服務代理（Broker）：已發布的消息保存在一組服務器中，它們被稱為代理（Broker）或Kafka集群；
4、消費者（Consumer）：可以訂閱一個或多個話題，並從Broker拉數據，從而消費這些已發布的消息；
上圖中可以看出，生產者將數據發送到Broker代理，Broker代理有多個話題topic，消費者從Broker獲取數據。
三、基本原理
我們將消息的發布（publish）稱作 producer，將消息的訂閱（subscribe）表述為 consumer，將中間的存儲陣列稱作 broker(代理)，這樣就可以大致描繪出這樣一個場面：
生產者將數據生產出來，交給 broker 進行存儲，消費者需要消費數據了，就從broker中去拿出數據來，然后完成一系列對數據的處理操作。
乍一看返也太簡單了，不是說了它是分布式嗎，難道把 producer、 broker 和 consumer 放在三台不同的機器上就算是分布式了嗎。看 kafka 官方給出的圖：
多個 broker 協同合作，producer 和 consumer 部署在各個業務邏輯中被頻繁的調用，三者通過 zookeeper管理協調請求和轉發。這樣一個高性能的分布式消息發布訂閱系統就完成了。
圖上有個細節需要注意，producer 到 broker 的過程是 push，也就是有數據就推送到 broker，而 consumer 到 broker 的過程是 pull，是通過 consumer 主動去拉數據的，
而不是 broker 把數據主懂發送到 consumer 端的。
四、Zookeeper在kafka的作用
1、Broker注冊
Broker是分布式部署並且相互之間相互獨立，但是需要有一個注冊系統能夠將整個集群中的Broker管理起來，此時就使用到了Zookeeper
2、Topic注冊
在Kafka中，同一個Topic的消息會被分成多個分區並將其分布在多個Broker上，這些分區信息及與Broker的對應關系也都是由Zookeeper在維護，由專門的節點來記錄，如：
/borkers/topics
3、生產者負載均衡
由於同一個Topic消息會被分區並將其分布在多個Broker上，因此，生產者需要將消息合理地發送到這些分布式的Broker上，那么如何實現生產者的負載均衡，
Kafka支持傳統的四層負載均衡，也支持Zookeeper方式實現負載均衡。
4、消費者負載均衡
與生產者類似，Kafka中的消費者同樣需要進行負載均衡來實現多個消費者合理地從對應的Broker服務器上接收消息，每個消費者分組包含若干消費者，
每條消息都只會發送給分組中的一個消費者，不同的消費者分組消費自己特定的Topic下面的消息，互不干擾。
5、消息 消費進度Offset 記錄
在消費者對指定消息分區進行消息消費的過程中，需要定時地將分區消息的消費進度Offset記錄到Zookeeper上，
以便在該消費者進行重啟或者其他消費者重新接管該消息分區的消息消費后，能夠從之前的進度開始繼續進行消息消費。Offset在Zookeeper中由一個專門節點進行記錄，其節點路徑為:
/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] 節點內容就是Offset的值。
詳情查看：
https://www.cnblogs.com/huazai007/articles/10990449.html
五、執行流程
首先看一下如下的過程：
我們看上面的圖，我們把 broker 的數量減少，叧有一台。現在假設我們按照上圖進行部署：
（1）Server-1 broker 其實就是 kafka 的 server，因為 producer 和 consumer 都要去還它。 Broker 主要還是做存儲用。
（2）Server-2 是 zookeeper 的 server 端，它維持了一張表，記錄了各個節點的 IP、端口等信息。
（3）Server-3、 4、 5 他們的共同之處就是都配置了 zkClient，更明確的說，就是運行前必須配置 zookeeper的地址，道理也很簡單，這之間的連接都是需要 zookeeper 來進行分發的。
（4）Server-1 和 Server-2 的關系，他們可以放在一台機器上，也可以分開放，zookeeper 也可以配集群。目的是防止某一台掛了。
簡單說下整個系統運行的順序：
（1）啟動zookeeper 的 server
（2）啟動kafka 的 server
（3）Producer 如果生產了數據，會先通過 zookeeper 找到 broker，然后將數據存放到 broker
（4）Consumer 如果要消費數據，會先通過 zookeeper 找對應的 broker，然后消費。
六、Kafka的特性
（1）高吞吐量、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作；
（2）可擴展性：kafka集群支持熱擴展；
（3）持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失；
（4）容錯性：允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）；
（5）高並發：支持數千個客戶端同時讀寫；
（6）支持實時在線處理和離線處理：可以使用Storm這種實時流處理系統對消息進行實時進行處理，同時還可以使用Hadoop這種批處理系統進行離線處理；
七、Kafka的使用場景
（1）日志收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種consumer，例如Hadoop、Hbase、Solr等；
（2）消息系統：解耦和生產者和消費者、緩存消息等；
（3）用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發布到kafka的topic中，
然后訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到Hadoop、數據倉庫中做離線分析和挖掘；
（4）運營指標：Kafka也經常用來記錄運營監控數據。包括收集各種分布式應用的數據，生產各種操作的集中反饋，比如報警和報告；
（5）流式處理：比如spark streaming和storm；
（6）事件源；
歡迎進群討論：QQ群294668383（有意向可以添加）