1樓：曹操
因為主流的註冊中心都是要求過半表決一致的資料一致性演算法，這就決定了集群在初始化的時候就需要知道自己集群的規模有多大，集群成員都有哪些人。
動態擴容一般會面臨兩個問題，第乙個：如何認識新人。新加入的節點，老的集群是不認識的，至少目前這塊做的很不好。
zookeeper 3.5.x的版本官方說支援動態擴容，但是到目前release版本也是遲遲發不出來，擴容的操作也是相當複雜。
第二個問題：擴容過程實施後，開始資料同步，加入此刻leader節點掛了，會發生什麼情況。新加入節點和原來的follower節點會不會亂起來。
後面可能會有新的產品或者老產品的公升級，能方便的支援動態擴容，但是協議肯定要配套修改的，個人見解。
2樓：
zookeeper節點擴充套件有效能問題
節點越多效能越差，主要是因為zookeeper沒有唯讀節點，所以有了consul這樣的分client和server的，所以consul是可以動態擴充套件的
eureka效能很高，前期隨便搞幾個節點就能支援幾萬幾千上萬的例項，沒有動態擴充套件的意義
註冊中心如果只是提供服務存根的話，類似於eureka，效能非常高，因為業務太簡單，註冊中心的麻煩的是要實現例項狀態發生變更的主動通知……
springcloud用分布式配置中心從github讀配置檔案合適嗎？
許雪裡 自薦 輕量級配置管理平台 XXL CONFA 輕量級 秒級動態推送 多環境 跨語言 跨機房 配置監聽 許可權控制 版本回滾 程式猿DD 如果儲存使用Git 使用Github 注意訪問許可權的設定，這裡會有一定的風險，搞錯了就暴露了。公網訪問會慢一些。使用Gitlab 可以私有化部署，從網路上...
分布式的環境下， MySQL和Redis如何保持資料的一致性？
EnjoyMoving 資料庫和快取之間一般不需要強一致性。一般快取是這樣的 讀的順序是先讀快取，後讀資料庫 寫的順序是先寫資料庫，然後寫快取 每次更新了相關的資料，都要把該快取清理掉 為了避免極端條件下造成的快取與資料庫之間的資料不一致，快取需要設定乙個失效時間。時間到了，快取自動被清理，達到快取...
請問分布式副本技術中 chain replication 有實際的落地場景嗎？
1412 我們組的自研分布式儲存系統就是chain replication的，目前線上大規模使用中。大家都知道分布式副本技術，有多種基本的共識模型，為了對比，不太系統地列一下 鏈式 1發1 樹狀 1發多 主從 1發所有 去中心化等。無論什麼模型，目的都是通過某個入口，把所有人都通知上。所以很容易看出...