1.為啥要用？
分布式中機器，應用很多，服務呼叫方需要知道介面位址，然後在配置檔案中配置，新加，修改配置檔案很頻繁，很不方便。
使用註冊中心，服務提供方和呼叫方將自己資訊放到註冊中心，即可使用。
2.常用的註冊中心：zookeepr,eurkea
3.zookeepr資料模型：
4.zookeepr操作命令
5.session機制
6.watcher機制：沒看懂
沒看懂為啥他要使用這個。
步驟：1.client向服務端按註冊，client觸發watcher;傳送watcher,會將client存放乙份到本地。
2.服務端向客戶端傳送訊息，將訊息存到
watcher操作 get stsat 對自己、子節點操作 刪除，新增會觸發，修改不會。孫子節點都不會生效。
7.acl許可權控制
8.選舉機制和選舉模式
三種角色
leader:集群中唯一可以寫請求的處理著，進行發起投票和決議
follower:接收客戶端請求，處理讀請求；將寫請求發給leader;參與選舉leader投票。
observer:沒有選舉許可權的follower.作用：在選舉的同時，可能會有很高的讀請求，它可以幫助follower在忙時處理讀請求，提高系統的處理量。
三種選舉模式
恢復模式：leader奔潰，會選乙個新leader，直到集群恢復工作。
同步模式：新leader選出後，多個follower會同步新leader上的內容，知道大多數follower同步完成，模式結束。恢復模式也結束。恢復模式包含了同步模式。
廣播模式：客戶端發起寫操作，leader發布廣播到follower，大多數follower同意，leader修改資料，建修改後結果廣播給其他follower
9.zk集群選舉狀態
兩個引數
1.myid：集群中伺服器唯一標識。
2. zxid: long型別。為64位，前32位：epoch 每個leader有乙個epoch ,新leader產生，就會有個epoch值，會同步到其他server的 epoch
後32位：xid 為zk的事務id，不知道咋用。
選舉狀態：
looking:選舉狀態
leading:領導狀態
following:隨從狀態
observing:觀察狀態：那些沒投票權的observe伺服器，在同步leader資料時狀態。
選舉發生的時機和選舉演算法：
集群剛啟動時候；leader奔潰時候
對比（myid，zxid），先對比zxid，zxid大者（大表示資料越新）勝出，成為leader，如果zxid一致，則myid
大者成為leader
雜記 分布式系統註冊中心
在大型的分布式專案當中，系統按照功能劃分為多個模組。每個模組由不同人編寫，實現不同的功能。每個模組都能對外提供服務。在前文當中，我們介紹rmi技術，能夠實現遠端方法呼叫，通過zookeeper能夠實現服務的註冊發現。本章整體介紹簡單分布式系統的實現過程。1.在分布式系統當中，每個模組都可以多節點部署...
分布式配置中心
部署演進 單機配置檔案部署 當隨著業務的使用者量增加，通常我們會把我們的服務進行多機器 集群 部署。這時候，配置的發布就變成了如下，多機器配置 1.2 分配式配中心 傳統配置的方式已經暴露出了很多問題，其餘的諸如 歷史版本管理，許可權控制，安全性等等問題，是傳統的配置檔案無法處理的 隨著業務的發展 ...
分布式配置中心
1 話題引入 如果配置檔案全部放在resources目錄下，管理起來非常複雜，所以採用分布式配置中心，放在git上 2 產生背景 在微服務中如果使用傳統的方式管理配置檔案，配置檔案管理器非常複雜 如果生產環境配置檔案，可能需要發生改變的時候，重新打war，重新讀取配置資訊在jvm記憶體中 3 什麼是...