架構 成了 自己的 kafka bsp ase 海量數據存儲 持久 主從架構

1.1 Zookeeper從文件系統API得到啟發，提供了一組簡單的API，使得開發人員可以實現通用的協作任務，包括選舉主節點、管理組內成員關系、管理元數據等。 zookeeper組件運行在一組專用的服務器上，保證了高容錯性和可擴展性。 zookeeper系統功能都圍繞在一條主線上：它可以在分布式系統中協作多任務。 zookeeper應用：

• apache Hbase中使用它選舉一個集群內的主節點，以便跟蹤可用的服務器，並保存集群的元數據。
• apache kafka使用它用於檢測奔潰，實現主體的發現，並保存主題的生產和消費狀態。

zookeeper的客戶端API功能強大，其主要包括：

• 保證強一致性、有序性和持久性
• 實現通用的同步原語的能力
• 在實際分布式系統中，並發往往導致不正確的行為，zookeeper提供了一種簡單的並發處理機制。

zookeeper不適用於海量數據存儲。 分布式系統中的通訊分為兩種：一種是直接他通過網絡進行信息交換 或者 是寫某些共享的存儲。zookeeper使用共享存儲模型來實現應用間的協作和同步原語。 正式的分布式系統中需要註意幾個問題：

• 消息延遲：消息可能由於網絡堵塞導致任意的延遲，這種延遲導致不可預期的後果。
• 處理器性能：操作系統的調度和超載也以後能導致消息處理的任意延遲。
• 時鐘偏移：使用時間概念的系統並不少見，處理器時鐘並不可靠，因此依賴處理器時鐘也有可能導致錯誤的決策。

1.2 主從應用示例 在一個主從架構中，主節點進行負責跟蹤從節點狀態和任務的有效性，並分配任務到從節點，要實現主從模式的系統，我們必須解決以下三個關鍵問題： 主節點崩潰：如果主節點發送錯誤並失效，系統將無法分配新任務或者重新分配已經失敗的任務。 從節點奔潰：如果從節點崩潰，已分配的任務將無法完成。 通訊故障：如果主節點和從節點之間無法進行信息交換，從節點將無法得知新任務分配 給自己。 1.2.1主節點失效 主節點失效時，需要一個備份主節點，當主節點崩潰時，備份主節點可以接管主要節點的角色，進行故障轉移。 其中還涉及到一個問題，即主節點有效，但是備份主節點認為主節點已經崩潰，這種錯誤的假設可能發生咋以下情況：例如主節點負載很高的情況下，導致消息任意延遲 還有一種情況，即主節點和備份主節點都任務自己的主節點，這種情況可能是由於網絡分區導致的“腦裂”：系統中兩個或者多個部分開始獨立工作，導致整體行為不一致。 1.2.2從節點失效 從節點崩潰，所有已經派發的任務並且尚未執行的任務都需要重新派發，其中首要需求是讓主節點發現檢測到從節點的崩潰。 1.2.3通訊故障 如果一個從節點和主節點的網絡連接斷開，可能是由於網絡分區導致的，重新分配一個任務可能導致兩個從節點執行相同的任務，如果一個任務允許多次執行，那麽我們不用檢測第一個從節點是否完成了該任務，如果一個任務不允許重新執行，那麽我們就需要適應多個從節點執行相同任務的可能性。 這裏需要考慮“僅一次”與“最多一次”的概念。 我們可以通過設置鎖或者臨時狀態來檢測任務是否正在執行，其次zookeeper需要客戶端定義發送是否存活的通知。通過以上兩種方式我們就可以預防客戶端獨立運行而發生的應用宕機。

第一章：簡介