zookeeper主要服務於分布式系統，可以看做乙個分布式協調系統，主要是用來解決分布式應用中經常遇到的一些資料管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。
上面的解釋有點抽象，簡單來說zookeeper =檔案系統+監聽通知機制。
zookeeper的資料結構，跟unix檔案系統非常類似，可以看做是一顆樹，每個節點叫做znode。每乙個節點可以通過路徑來標識，結構圖如下：
zookeeper的節點我們稱之為znode，每個節點都可以儲存資料，每個節點都有版本，znode分為兩種型別：
上面已經簡單介紹了zookeeper的資料結構了，它還要配合***才能做到那麼多功能。
客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（資料改變、被刪除、子目錄節點增加刪除）時，zookeeper會通知客戶端。
常見的監聽場景有以下兩項：
就這麼簡單，通過監聽+znode節點(持久/短暫[臨時])，zookeeper就可以玩出這麼多花樣了。
我們自己做專案時用到的配置比如資料庫配置等，我們都是寫死在專案裡面的。如果需要更改，那麼也是的修改配置檔案然後再投產上去，那麼問題來了，如果做集群的呢。有100臺機器，這時候做修改那就太不切實際了；那麼就需要用到統一配置管理。
解決思路：
zookeeper的命名服務功能主要是根據指定名字來獲取資源或服務的位址，提供者等資訊，利用其znode的特點和watcher機制，將其作為動態註冊和獲取服務資訊的配置中心，統一管理服務名稱和其對應的伺服器列表資訊，我們能夠近乎實時地感知到後端伺服器的狀態(上線、下線、宕機)。
舉例來說，b服務部署在六台伺服器上，存在六個完全不同的ip位址，同時b服務本身提供乙個dubbo介面對外，此時有個a服務需要呼叫此介面，如果提供某一台伺服器的ip，則存在該伺服器宕機情況下介面不可用的情況，再切換ip就會影響服務的正常使用。此時，可以使用zookeeper作為註冊中心，b服務的六台服務在指定znode下建立子節點，而a服務呼叫之前先通過指定znode的路徑獲取b服務的任意子節點中的ip資訊，然後通過ip訪問。同時zookeeper動態維護這部分節點，定時利用心跳請求檢查b服務的伺服器狀態，一旦發現某伺服器無反饋，就刪除節點，防止被a服務獲取呼叫。
當 a，b，c三個系統同時去訪問/lock節點時：
mysql用大白話解釋 大白話說說mysql索引
前面其實寫了好幾篇關於 mysql 索引的文章了，文章中有具體的例項和 sql 語句，這篇文章我想再用純大白話講講 mysql 索引，文中不涉及具體 sql 我之前甚至想過為啥要用資料庫來儲存資料，用普通的 txt 或者 word 這類檔案不行麼，這個問題其實可以從幾個方面來看，乙個是併發訪問資料加...
快速排序（大白話）
假設我們現在對 6 1 2 7 9 3 4 5 10 8 這個10個數進行排序。首先在這個序列中隨便找乙個數作為基準數 不要被這個名詞嚇到了，就是乙個用來參照的數，待會你就知道它用來做啥的了 為了方便，就讓第乙個數6作為基準數吧。接下來，需要將這個序列中所有比基準數大的數放在6的右邊，比基準數小的數...
大白話解釋 氣泡排序
原理 乙個陣列裡，相鄰的兩個元素進行比較，兩兩比較。使用雙層for迴圈，外層迴圈代表比較的輪數 陣列元素個數 1 內層迴圈代表每輪比較多少次 陣列元素個數 1 public class bubblesort for int i 0 ia j 1 system.out.println arrays.t...