zookeeper和Kafka的關係
01
Kafka選擇使用Zookeeper來進行Broker的管理，表現在zookeeper上會有一個專門用來進行Broker伺服器列表記錄的點，節點路徑為/brokers/ids
只要Broker伺服器啟動，都會到Zookeeper上進行註冊，建立/brokers/ids/[0-N]的節點，然後寫入IP，埠等資訊，Broker建立的是臨時節點，一旦Broker上線或者下線，對應Broker節點也就被刪除了。因此可以通過zookeeper上Broker節點的變化來動態表徵Broker伺服器的可用性,Kafka的Topic也類似於這種方式。
02
負載均衡，生產者需要將訊息合理的傳送到分散式Broker上，這就面臨如何進行生產者負載均衡問題。
對於生產者的負載均衡，Kafka支援傳統的4層負載均衡，zookeeper同時也支援zookeeper方式來實現負載均衡。
使用zookeeper進行負載均衡，生產者通過監聽zookeeper上Broker節點感知Broker，Topic的狀態，變更，來實現動態負載均衡機制，這個機制Kafka已經結合zookeeper實現了。
03
記錄訊息分割槽與消費者的關係，都是通過建立修改zookeeper上相應的節點實現
04
記錄訊息消費進度Offset記錄，都是通過建立修改zookeeper上相應的節點實現。
Kafka 對應多個broker(zookeeper)
⑴啟動 ZooKeeper
set KAFKA_HOME=D:/0_Shangbo/App/kafka/kafka_2.12-1.1.0cd %KAFKA_HOME%/bin/windowszookeeper-server-start.bat %KAFKA_HOME%/config/zookeeper.properties⑵啟動 Kafka borker
把 config 目錄下的 server.properties 複製兩份。分別命名為 server-1.properties 和 server-2.properties。修改這兩個檔案的下列屬性，確保 log 目錄存在。server-1.properties:
1.broker.id=1
2.listeners=PLAINTEXT://:9093
3.log.dirs=D:/0_Shangbo/App/kafka/data/kafka/broker1
server-2.properties:
broker.id=2
listeners=PLAINTEXT://:9094
log.dirs=D:/0_Shangbo/App/kafka/data/kafka/broker2
分別啟動broker
建立topicset KAFKA_HOME=D:/0_Shangbo/App/kafka/kafka_2.12-1.1.0
cd %KAFKA_HOME%/bin/windows
kafka-server-start.bat %KAFKA_HOME%/config/server.properties
如何建立圖中所示topic，請自行研究。
Redis與Zookeeper分散式鎖實現區別基於Redis實現分散式鎖（setnx）setnx也可以存入key，如果存入key成功返回1，如果存入的key已經存在了，返回0.基於Zookeeper實現分散式鎖 Zookeeper是一個分散式協調工具，在分散式解決方案中。多個客戶端（jvm），同時在zk上建立相同的一個臨時節點，因為臨時節點路徑是保證唯一，只要誰能夠建立節點成功，誰就能夠獲取到鎖，沒有建立成功節點，就會進行等待，當釋放鎖的時候，採用事件通知給客戶端重新獲取鎖的資源。kafka與redis的區別kafka是訊息佇列，訊息的儲存模型只是其中的一個環節，還提供了訊息ACK和佇列容量、消費速率等訊息相關的功能。redis訊息推送（基於分散式 pub/sub）多用於實時性較高的訊息推送，並不保證可靠。mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis是記憶體資料庫，只是它的list資料型別剛好可以用作訊息佇列而已。redis-pub/sub斷電就清空，使用redis-list作為訊息推送雖然有持久化，但是又太弱智，也並非完全可靠不會丟。redis 釋出訂閱除了表示不同的 topic 外，並不支援分組，比如kafka中釋出一個東西，多個訂閱者可以分組，同一個組裡只有一個訂閱者會收到該訊息，這樣可以用作負載均衡。處理資料大小的級別不同高併發下環境搭建
需要搭建叢集，三者之間關聯。
⑴zookeeper叢集
zk 是用來協同分散式系統之間的工作的。CAP 一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance）中的CP
為了保證高可用 和 更大的 併發讀。不是為了分散資料儲存，因為ZK不是設計用來儲存大量資料的。
1個leader，多個follower所有的server 都是最終資料一致leader 職責：接受follower寫請求，同步請求，發起投票，接收follower對提議的回覆follower 職責：接收客戶端請求並返回請求結果、參與投票⑵kafka叢集
分為：控制器、分割槽首領 和 跟隨者。
控制器只是一個broker,不僅提供正常的服務，還要提供首領選舉的能力。負責為失去首領的分割槽找到新的首領
分割槽首領處理來自客戶端的生產者的訊息請求
跟隨者只是複製訊息，因為每個broker可儲存成百上千不同主題與分割槽的副本，若一個broker離開了叢集，可能會讓在該broker的分割槽副本失去分割槽首領，因此 控制器會為這些分割槽重新選舉一個分割槽首領。
若控制器離開了叢集，則其他broker會收到ZK 的通知，然後會去嘗試成為新的控制器，第一個成功，其餘失敗。則繼續註冊監聽新的控制器節點。
選舉依賴於ZK叢集⑶redis叢集的搭建
redis cluster叢集(高可用、資料分散，總可儲存資料變大)：
多個 主-從 結構。CAP 一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance）中的AP
主節點處理請求，從節點只是同步資料
各個主節點儲存的資料不同。
主從切換