1、分散式存在的問題

• 分散式解決的問題：資源不夠的問題
  • 通過分散式的資源整合，將儲存或者計算交給多臺機器並行處理
• 問題一：大的任務一臺機器解決不了
  • 40TB檔案
  • 普通一臺機器：32TB，無法儲存
• 問題二：即使一臺機器能解決，但是效能比較差
  • 40TB檔案：寫速度1s/1TB
  • 特殊一臺機器：64TB，可以儲存40s
  • 分散式叢集儲存：16TB x 4 臺，總共64TB ，可以儲存10s：高併發的
• 大資料中：越快越好
  • 資料的價值會隨著時間的流逝而逐漸降低
• 分散式本身存在的問題
  
• node4當機了 ，主服務就沒有了
  • 整個分散式叢集就癱瘓了
  • 沒有服務能接受請求以及管理所有的任務
• 如果產生了兩個主服務怎麼辦？
  • 如果同一時刻出現了 兩個主服務，功能一模一樣，客戶端請求誰？誰來負責管理？
• 在這樣的分散式架構中，如果我們需要更改程式碼的配置怎麼辦？
  • 總共有100臺機器
  • 如果不做分散式管理：就需要手動替換100臺機器的程式碼
• 即使我們將程式碼都更改了，如何保證這100臺機器的程式碼配置是一樣的？
• 假設：100臺機器的程式碼配置的JDBC連線屬性都必須是一致的
  • 突然，公司要更換資料庫叢集，地址發生改變，需要修改jdbc配置
• 問題
  • 資料一致性問題
  • 分散式同步鎖問題
  • 單節點故障

2、Zookeeper的功能

一致性服務

存放共同配置

• 將所有重要的可能產生變化的配置儲存在Zookeeper中
• 所有的分散式節點，在需要讀取這個配置的時候，直接從Zookeeper中讀取這個配置
• 如果要修改，只要更改Zookeeper中的配置即可

註冊中心

• 所有功能相同的服務節點，都要向zookeeper進行註冊，才能實現應用

命名服務

構建整體，統一入口

• 將統一功能節點構建一個統一的命名，作為一個整體，在zookeeper中將兩個主服務構建成一個整體
• 等客戶端請求的時候，先請求zookeeper，zookeeper中會記錄誰是工作的，誰是備份的，將請求轉發給工作狀態的節點

分散式鎖

• 兩個主服務
• 如果有一個主服務是工作狀態的，另一個主服務能不能是工作狀態的？
  • 不能
• 所有的主服務向Zookeeper進行註冊，並且參加選舉，會選舉出一個工作的主服務，一旦選舉成功
• 其他的主服務是不允許作為工作狀態的，只能成為備份狀態
  選舉的過程
• 第一種方式：搶注誰建立成功，誰就是主服務臨時節點
  • 所有的主服務都會一起到zookeeper中建立一個檔案
  • 誰建立成功，誰就是工作狀態，其他的就是備份狀態
    
• 第二種方式：排號大家都建立一個檔案，這個檔案按照建立的先後順序編號，誰的編號最小，誰就是工作狀態，其他的是備份狀態有序臨時節點
• 備份的什麼時候會自動變成工作狀態呢？
  • 所有的備份服務都會監聽工作狀態所建立的那個檔案
  • 如果工作狀態的服務故障了，這個檔案會自動消失
  • 如果這個檔案自動消失，那麼所有的備份服務會重新選舉

選舉

• 保證叢集中選舉出一個工作的主服務
• 如果工作的主服務故障了，要從多個備份的主服務中選舉出一個新的工作主服務

資料釋出訂閱

• 將一些關鍵性的資料，很多程式都想要的資料儲存在Zookeeper中
• 生產者：負責往Zookeeper中寫入資料
• 消費者：負責從Zookeeper中讀取資料

總結

• 統一化的資料一致性：關鍵性的資料共享的資料保持一致
• 註冊中心
• 選舉：誰是主節點?幫別的工具中的服務選舉
• 命名服務:請求誰?
• 分散式鎖:不能同時是主節點啊?