master選舉使用場景及結構
現在很多時候我們的服務需要7*24小時工作，假如一台機器掛了，我們希望能有其它機器頂替它繼續工作。此類問題現在多採用master-salve模式，也就是常說的主從模式，正常情況下主機提供服務，備機負責監聽主機狀態，當主機異常時，可以自動切換到備機繼續提供服務(這裡有點兒類似於資料庫主庫跟備庫，備機正常情況下只監聽，不工作)，這個切換過程中選出下乙個主機的過程就是master選舉。
三個核心選舉原則：
（1）zookeeper集群中只有超過半數以上的伺服器啟動，集群才能正常工作；
（2）在集群正常工作之前，myid小的伺服器給myid大的伺服器投票，直到集群正常工作，選出leader；
（3）選出leader之後，之前的伺服器狀態由looking改變為following，以後的伺服器都是follower。
下面以乙個簡單的例子來說明整個選舉的過程：
假設有五颱伺服器組成的zookeeper集群，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史資料，在存放資料量這一點上，都是一樣的。
假設這些伺服器從id1-5，依序啟動：
因為一共5臺伺服器，只有超過半數以上，即最少啟動3臺伺服器，集群才能正常工作。
（1）伺服器1啟動，發起一次選舉。
伺服器1投自己一票。此時伺服器1票數一票，不夠半數以上（3票），選舉無法完成；
伺服器1狀態保持為looking；
（2）伺服器2啟動，再發起一次選舉。
伺服器1和2分別投自己一票，此時伺服器1發現伺服器2的id比自己大，更改選票投給伺服器2；
此時伺服器1票數0票，伺服器2票數2票，不夠半數以上（3票），選舉無法完成；
伺服器1，2狀態保持looking；
（3）伺服器3啟動，發起一次選舉。
與上面過程一樣，伺服器1和2先投自己一票，然後因為伺服器3id最大，兩者更改選票投給為伺服器3；
此次投票結果：伺服器1為0票，伺服器2為0票，伺服器3為3票。此時伺服器3的票數已經超過半數（3票），伺服器3當選leader。
伺服器1，2更改狀態為following，伺服器3更改狀態為leading；
（4）伺服器4啟動，發起一次選舉。
此時伺服器1，2，3已經不是looking狀態，不會更改選票資訊。交換選票資訊結果：伺服器3為3票，伺服器4為1票。
此時伺服器4服從多數，更改選票資訊為伺服器3；
伺服器4並更改狀態為following；
（5）伺服器5啟動，同4一樣投票給3，此時伺服器3一共5票，伺服器5為0票；
伺服器5並更改狀態為following；
git刪除master分支並替換master分支
背景 由於master分支進行回滾後，合特性分支無法將之前回滾的 再合併進去，所以需要拿本地的分支作為master分支 前提是本地分支和回滾前的master分支保持一致，不然會導致之前在生產的 被覆蓋，為什麼不能從master分支拉取乙個特性分支呢？拉取後的特性分支合併本地分支回滾的 還是無法合併進...
Zookeeper 實現持續監聽
zookeeper預設監聽觸發一次就結束，所以需要重新實現watchedevent中的process方法，核心就是對watcher的迴圈呼叫 watchedevent包含兩方面重要資訊 可以呼叫watchedevent.getstate 方法獲取與zk伺服器連線的狀態資訊，狀態資訊取值主要包括syn...
Dubbo基於Zookeeper實現分布式服務
點關注不迷路，歡迎再訪！精簡部落格內容，盡量已行業術語來分享。努力做到對每一位認可自己的讀者負責。幫助別人的同時更是豐富自己的良機。既然是新手教學，肯定很多同學不明白什麼是分布式和遠端服務呼叫，為什麼要分布式，為什麼要遠端呼叫。下圖為例 以前什麼的都在乙個伺服器上，呼叫方法直接就自然而然呼叫了，沒啥...