cp模型：distro 協議，如果選ephemeral （臨時節點），則全部在記憶體中操作，則支援類似於distro 協議，服務端節點都儲存所有資料，但每個節點只負責其中一部分服務，在接收到客戶端的「寫「（註冊、心跳、下線等）請求後，服務端節點判斷請求的服務是否為自己負責，如果是，則處理，否則交由負責的節點處理；這樣可以避免寫單點的問題。
ap模型：raft協議，如果選非ephemeral （非臨時節點），則支援raft 選主，並持久化到本地檔案，服務註冊、心跳、下線等請求都有leader 節點負責，follower節點負責同步狀態，同時 follower節點只負責讀請求
防止多節點讀寫併發衝突，比如：節點服務正在註冊，不影響其他節點正常執行，eureka是使用二級快取實現的，乙個負責唯讀，乙個負責讀寫，然後主map定時同步到唯讀快取map;
nacos 是使用copy on write技術實現
比如eureka1.0，client端沒有權利選擇自己關注的服務或者ip位址，所有的註冊內容照單全收，譬如乙個老師的service，它可能只需要關心學生service，對它來說警察service跟它沒有任何關係，這樣的優化可以讓服務更新減少很大的流量。
eureka1未將poll的模式改為push，因為poll模式最大的缺點就是 「沒改變時白拉，改變了有遲拉」，push的方式是一種比較自然的事件通知的方式。 nacos用的是長輪詢模式
eureka1 v1.0時使用的是廣播全量資料複製的方式，它要求將所有狀態資料和心跳都同步到配置的每個peer上，這樣每個peer上都承擔了相同的所有流量，對頻寬的壓力還是非常大的。eureka v2.0開始將分為寫集群和讀集群，根據client的數量和流量來動態擴充套件讀集群，但是 eureka2.0 變成閉源收費模式
支援服務級別的元資料、集群級別的元資料、例項級別的元資料；
可以配置權重效能好的權重配置高，效能低的配置權重低
灰度可以配置集群，比如標識 北京機房、上海機房；未來可能實現雙機房服務中心
註冊中心掛了以後，客戶端有快取，可以繼續工作
被呼叫方服務剔除以後，及時通知客戶端快取剔除不可用的被呼叫方
seata 的註冊中心和配置中心
註冊中心 服務端註冊中心 位於seata server的registry.conf配置檔案中的registry.type引數 為了實現seata server集群高可用不會使用file型別，例如下邊 表示 使用zookeeper作為seata服務們的註冊管理中心，當前seata服務將會交由這個zk管...
基於naocs做註冊中心和配置中心實踐
啟動命令 standalone代表著單機模式執行，非集群模式 sh startup.sh standalone 1.2 windows 啟動命令 cmd startup.cmd 雙擊啟動 或者雙擊startup.cmd執行檔案。1.3 開啟控制台 登入名 nacos 密碼 nacos 注意 spri...
spring cloud 註冊中心配置
注意事項 必須要勾上eureka server選項 1.配置埠 server.port 5121 2.配置eureka主機名，找到eureka所在的機器 eureka.instance.hostname localhost 3.是否將自身註冊為服務 false表示不註冊 eureka.client....