本文來自於《精通Spring Cloud Alibaba》課程的整理，講師為餘勝軍，點擊查看視頻內容。
本文系志願者整理，供配合學習中心課程使用，不做商業用途。
基於Nacos集群部署方案
Nacos的集群部署
Nacos 核心幫助我們做的事情註冊中心、分佈式配置中心
註冊中心：沒有必要將數據持久化到數據庫中，可以持久化到本地的硬盤。
分佈式配置中心： 默認是將數據持久化到本地嵌入式的數據庫改為持久化到myql中
創建cluster文件夾
---nacos-server-8848
---nacos-server-8849
---nacos-server-8850
cluster.conf
ip和端口號
127.0.0.1:8848
127.0.0.1:8849
127.0.0.1:8850
Nginx相關配置
客戶端連接
spring:
application:
###服務的名稱
name: meitemayikt-nacos-client
cloud:
nacos:
discovery:
###nacos註冊地址
server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
enabled: true
config:
###配置中心連接地址
server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
###分組
group: DEFAULT_GROUP
###類型
file-extension: yaml
注意：
1、Nacos在不同的版本下運行集群是不一樣的。
nacos在windows版本下運行默認是單機版本 需要指定startup.cmd -m cluster
2、nacos在linux版本下運行默認是集群版本 如果想連接單機版本 startup.cmd –m standalone
注意事項：集群的ip地址不能採用127.0.0.1，我們需要修改為192.168.18.218。
分佈式情況下 集群保證數據的一致性集群的算法
ZAB（Zookeeper）核心原理兩階段是提交協議2PC、Paxos、nacos數九一致性協議raft協議採用心跳形式
Nacos的數據持久化
數據持久化
默認的情況下，分佈式配置中心的數據存放到本地data目錄下，但是這種情況如果nacos集群的話無法保證數據的同步性。
在0.7版本之前，在單機模式時nacos使用嵌入式數據庫實現數據的存儲，不方便觀察數據存儲的基本情況。在0.7版本增加了支持mysql數據源能力，具體的操作步驟：
1、安裝數據庫，版本要求：5.6。5+
2、初始化mysql數據庫，數據庫初始化文件：nacos-mysql.sql
3、修改conf/application.properties文件，增加支持mysql數據源配置（目前只支持mysql），添加mysql數據源的url、用戶名和密碼。
相當於配置文件數據源，統一放到數據庫中。
Nacos與Eureka區別
1、Eureka採用ap模式形式實現註冊中心
2、Nacos默認採用AP模式。在1.0版本之後採用ap+cp模式混合實現註冊中心。
Eureka與Nacos底層實現集群協議那些區別
1、去中心化對等。
2、Raft協議實現集群產生領導角色。
Raft到底是什麼問題 分佈式一致性協議的算法
分佈式系統一致性算法 應用於系統軟件實現集群保持每個節點數據的同步性
保持我們的集群中每個節點的數據的一致性的問題，專業的術語分佈式一致性的算法。
場景：Redis集群、nacos集群、mongdb集群等
最大區別：Nacos支持兩種模式CP/Ap模式，從Nacos1.0版本開始，注意模式就是Ap模式
註冊有哪些？
Eueeka、Nacos、consul、Zookepper
核心：
1、Eureka與Zookeeper實現註冊的區別
2、Eureka與Nacos實現註冊區別
CAP定律概念：
一致性(C):在分佈式系統中，如果服務器是計群的情況下，每個節點同一時刻查詢的數據必須保持一致性的問題。
可用性（A）:集群節點中，部分的節點出現了故障後仍然可以使用
分區容錯性（P）:在分佈式系統中網絡存在腦裂的問題，部分的Server與整個集群失去聯繫
採用：
Cp情況下 雖然我們服務不能用，但是必須要保證數據的一致性
Ap情況下 可以短暫保證數據不一致性，但是最終可以一致性，不管怎麼樣，要能夠保證我們的服務可用
大多的註冊中心都是Ap
Zab協議集群原理
我們在分佈式系統，存在多個系統之間的集群保持數據一致性，採用CP一致性算法保持數據的一致性問題。
Zookeeper基於ZAP協議實現保持每個節點的數據同步的問題，中心化思想集群模式；
分為領導和跟隨角色。
在程序中如何成為某個節點能力比較強：
對每個節點配置一個myid或者serverid還有數值越大表示能力越強 或者隨機時間
整個集群中為了保持數據的一致性的問題，必須滿足大多數情況>n/2+1 可運行的節點環境下才可以使用
ZAP的協議實現原理事通過比較myid myid誰最大誰就是為可能是領導角色，只要滿足過半的機制就可以成為領導角色，後來啟動的節點不會參與選舉的。
Zab協議如何保持數據的一致性問題
所有寫的請求統一交給我們的領導角色實現，領導角色寫完數據之後，領導角色再將 數據同步給每個節點。
注意：數據之間同步採用2pc兩個階段提交協議。
選舉過程：
先去比較zxid zxid誰最大誰就是為領導角色；
如果zxid相等的情況下，myid誰最大誰就為領導角色；
Raft協議選舉的基本概念
在Raft協議算法中分為角色|名詞：
1、狀態：分為三種 跟隨者、競選者（候選人）、領導角色
2、大多數：>=n/2+1 3/2=1+1=2
3、任期：每次選舉一個新的領導角色 任期都會 實現增加
注意：任何算法都來源於生活
4、競選者誰的票數最多，誰就是為領導角色
存在的疑問：
多個競選者，產生的票數都一樣，這到底誰是領導角色，服務器集群是偶數的情況下
Nacos對比Zookeeper、Eureka之間的區別
CAP定律
這個定理的內容是指的是在一個分佈式系統中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一致性(C)：在分佈式系統中，如果服務器集群，每個節點在同時刻訪問必須要保持數據的一致性。
可用性(A)：集群節點中，部分節點出現故障後任然可以使用 （高可用）
分區容錯性(P)：在分佈式系統中網絡會存在腦裂的問題，部分Server與整個集群失去節點聯繫，無法組成一個群體。
只有在CP和AP選擇一個平衡點
Eureka與Zookeeper區別
相同點、不同點、中心思想
相同點：都可以實現分佈式服務註冊中心
不同點：Zookeeper採用CP保證數據的一致性的問題，原理採用Zab原子廣播協議，當我們的zk領導因為某種原因宕機的情況下，會自動觸發重新選一個新的領導角色，整個選舉的過程為了保證數據的一致性問題，在選舉的過程中整個zk環境是不可使用的可短暫可能無法使用到zk。意味著微服務採用該模式情況下，可能無法實現通訊（本地有緩存除外）
注意：可運行的節點必須滿足過半機制，整個zk採用使用。
Eureka採用ap的設計理念架構註冊中心，完全去中心化思想，也就是沒有主從之分
每個節點都是均等，採用相互註冊的原理，你中有我我中有你，只要最後有一個eureka節點存在就可以保證整個微服務可以實現通訊。
我們在使用註冊中心，可用性在優先級最高，可以讀取數據短暫不一致性，但是至少要能夠保證註冊中心可用性。
中心化 必須圍繞一個領導角色作為核心，選舉領導和跟隨者角色
去中心化 每個角色都是均等
分佈式系統一致性算法
分佈式事務性一致性框架與分佈式系統一致性算法有哪些
分佈式事務一致性框架：核心解決我們在實際系統中產生誇事物導致分佈式事務問題。
核心靠的是最終一致性：rocketmq事務消息、rabbitmq補單、lcn、SeaTac等。
分佈式系統一致性算法：解決我們系統之間集群之後每個節點保持數據的一致性
有哪些：raft（nacos）、zab（zookeeper）、paxos等。
如何保持數據的一致性的問題
所有寫的請求統一交給我們的領導角色實現，領導角色寫完數據之後，領導角同步給每個節點。
注意：數據之間同步採用2pc兩階段提交協議。
在我們分佈系統中，存在多個系統之間實現數據的集群，採用CP一致性算法保證每個節點數據的一致性的問題。
比如Eureka、Zookeeper、Nacos實現集群都必須保證每個節點數據同步性的問題。
Zookeeper基於ZAP協議實現保證每個節點數據同步的問題，中心化思想集群模式。分為領導和跟隨者角色。
Eureka基於AP模式實現註冊中心，去中心化的思想、每個節點都是對等的，採用你中有我我中有你的形式實現註冊中心。
常見分佈式一致性算法：
1、ZAP協議（底層就是基於Paxos實現）， 核心底層基於2PC兩階段提交協議實現。
2、Nacos中集群保證一致性算法採ratf協議模式，採用心跳機制實現選舉的。
Ratf整個底層實現原理：
在Raft協議算法中分為角色|名詞：
1、狀態：分為三種，跟隨者、競選者（候選人）、領導角色。
跟隨者：只有投票權限，不能參與競選。
競選者（候選人）：被投票，有可能成為領導者的角色。
領導角色：只有唯一的一個。
2、大多數： >n/2+1，n表示集群總數的節點。
3、任期：每次選舉一個新的領導角色，任期都會增加。
注意：任何的算法都是來源於生活。
4、競選者誰的票數最多，誰就成為領導角色。
存在的疑問：
多個競選者，產生的票數都完全一樣，這到底誰是領導角色？
注意當我們的集群節點總數，如果是奇數情況下，就算遇到了該問題也不用擔心。
當我們的節點是偶數的情況下，可能會存在該問題，如果兩個競選者獲取的票數相等的情況下，開始重置競選的超時時間，一直到誰的票數最多誰就為領導。
選舉過程是怎樣的呢：
先去比較zxid，zxid誰最大誰就是為領導角色；
如果zxid相等的情況下，myid誰最大誰就為領導角色；
默認情況下選舉的過程：
1、默認的情況下每個節點都是跟隨者角色
2、每個節點會隨機生成一個選舉的超時時間，例如大概是100-300ms，在這個超時時間範圍內必須要等待。
3、超時時間過後，當前節點的狀態由跟隨者變為競選者狀態，會給其他的節點發出選舉的投票通知，只要該競選者有超過半數以上即可選為領導角色。
核心的設計原理：誰超時時間最短，誰就有非常大的概率為領導角色。
那麼在隨機數有可能一樣的情況下，如何選舉呢？
1、如果所有的節點的超時隨機數都是一樣的情況下，當前投票全部作廢，重新進入隨機生成超時時間。
2、如果有多個節點生成的隨機數都是一樣的情況下，比較誰的票數最多，誰就是領導。如果票數完全一樣的情況，直接作廢，重新進入隨機生成超時時間。
注意：建議集群節點為奇數。偶數節點容易造成死循環。
故障重新實現選舉：
1、如果我們跟隨者節點不能夠及時的收到領導角色消息，那麼這時候跟隨者就會將當前自己的狀態由跟隨者變為競選者狀態，會給其他的節點發出選舉投票的通知，只要該競選者有超過半數以上即可選舉為領導角色。
數據是如何保持一致性的，類似於ZAP兩階段提交協議
如何實現日誌的複製
1、所有的寫的請求都是統一的交給我們的領導角色完成，寫入該對應的日誌，標記該日誌為被提交狀態。
2、為了提交該日誌，領導角色就會將該日誌以心跳的形式發送給其他的跟隨者節點，只要滿足過半的跟隨者節點寫入該目志，則直接通知其他的跟隨者節點同步該數據，這個過程稱為日誌複製的過程。