| 特性 | zookeeper | nacos |
|---|---|---|
| 一致性協議 | CP | CP+AP |
| 健康檢查 | Keep Alive | TCP / HTTP / MySql / Client beat |
| 負載均衡 | 無 | 權重 / selector / metadata |
| 多資料中心 | 不支持 | 支持 |
| 跨注冊中心同步 | 不支持 | 支持 |
| 雪崩保護 | 無 | 有 |
| 訪問協議 | TCP | HTTP / DNS |
| K8s集成 | 不支持 | 支持 |
| dubbo集成 | – | 支持 |
一致性協議
在介紹一致性協議前先了解一下CAP理論
- Consistency 一致性，在分布式系統中的所有資料備份，在同一時刻是否同樣的值；
- Availability 可用性，只要收到用戶的請求，服務器就必須給出回應；
- Partition tolerance 磁區容錯性，以實際效果而言，磁區相當于對通信的時限要求，系統如果不能在時限內達成資料一致性，就意味著發生了磁區的情況，必須就當前操作在C和A之間做出選擇
分布式系統必須具有磁區容錯性，一致性與可用性只能選擇其一，如果選擇一致性，必須在某節點寫入時，資料同步到其他節點完成后才可以回應下一個請求，這段時間內服務是不可用的；反之選擇可用性，則一致性無法保證，這就是CAP理論
作為注冊中心，P要保證，C和A需要權衡；常見的一致性協議有paxos、raft，他們都是強一致性協議（CP），然而今天要介紹的nacos的distro協議時弱一致協議（AP），即最終一致性協議，注冊中心到底該是AP還是CP，推薦閱讀阿里中間件的博客《阿里巴巴為什么不用 ZooKeeper 做服務發現？
》
為啥要保持一致性？
因為Nacos 是一個需要存盤資料的中間件，因此就需要在 Nacos 內部實作資料存盤，單機下其實問題不大，簡單的內嵌關系型資料庫即可；但是集群模式下，就需要考慮如何保障各個節點之間的資料一致性以及資料同步，而要解決這個問題，就不得不引入共識演算法，通過演算法來保障各個節點之間的資料的一致性，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/438077.html
標籤：其他
上一篇：hadoop完全分布式02