CAP准則
一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）
一致性：一個集群里，無論從哪台機器訪問，數據都是一致的
可用性：在可用節點上，能夠正常提供服務，一般指的不會出現大量超時，錯誤等問題
分區容錯性：集群中的節點出現宕機，依然能夠正常提供服務
注意：三個准則中只能選擇其中兩種！！！
沖突原因：
保證C：如果要保證C的話，那么必須要等這條命令的修改執行到了所有服務器上，主從上都有這個修改，那么就必須等主服務器進行了命令傳播后，才能回復客戶端
保證A：如果要保證A的話，那么一條命令的執行時間就必須在規定的范圍內，不能太久，及時給客戶端作出響應
保證P：如果要保證P的話，那么一個節點壞了的時候需要有從服務器及時替上
🌰：選擇CA，不用P？
如果選擇CA的話，說明我們要保證數據同步保持一致並且不會超時，我們只有一台服務器的時候可以直接本地執行完然后直接返回消息，每次訪問都是
都是一致的，因為只有一台服務器不需要同步，但是如果要P的話，就要考慮集群節點壞的時候需要其他從服務器替上，那么進行修改的時候就需要同步到所有的從服務器再返回修改，只有等同步完所有的之后才能主服務器返回響應，但是這樣就會超時AP之間有沖突
🌰：選擇CP，不用A？
如果選擇CP的話，說明我們可以給時間去同步所有的從服務器，去保證數據一致，但是相應的時間也會花很久，那么我們就無法保證A
🌰：選擇AP，不用C？
如果選擇AP的話，說明我們可以直接主服務器做了修改后就給客戶端響應，然后去異步的命令傳播給其他從服務器，但是有可能其中某些從服務器的包丟失，那么其他請求過來訪問的時候就有可能出現數據不一致的情況
選取模型
最常用的話就是AP了，一般為了保證一直能夠提供服務就要使用集群，P必須要保證，在C，A之中，A>C ，一般就會犧牲一致性，但是可以會用辦法去保證最終一致
看使用場景，銀行這種涉及💰方面的話，C就比較重要，然后保證A，可以喪失P，一時的故障沒有問題
AKF原則
在企業設計架構的時候，考慮AKF原則，x軸考慮高可用，一個節點的數據需要做備份，越大代表備份越多，y軸代表將一個節點的數據細分成多個模塊，想微服務將業務上細分成多個模塊，還有一個z軸，代表當細分成了多個模塊之后，一個模塊的並發依然很大，還需要細分，那么就需要把一個模塊的數據分成多台機器存儲，但是需要知道數據存在了哪台服務器上，就需要算法計算在哪台機器
A模型：算法寫在每個客戶端這，如果需要修改算法，每個客戶端都需要修改
B模型：找一個代理，每個客戶端訪問先經過一個代理，代理做計算，然后訪問具體機器
C模型：服務器自身進行算法划分，redis的做法就是分了16384個槽，然后每台服務器各自占了其中一部分槽，如果key屬於該槽，那么就由這條命令執行
raft
分布式一致性算法，一般用於主從服務器，主服務器掛掉之后如何選舉
簡單說一下實現，三個角色，leader（主） ， follower（從） ，candidate（參與投票的候選人）
每個節點都有一個定時器，每個節點的過期時間不一樣，如果一個節點的定時器歸零了，那么這個節點就會成為candidate，然后讓其他節點給自己投票，出現多個的話就會同時要票，如果沒有超超過半數就會重新選舉，票是先到先得的，如果超過半數，那么就會成為新的leader節點，這只是在於leader節點掛了的話，才會出現定時器歸零，如果leader沒有掛掉，那么就會定期發送心跳包，follower節點接收到心跳包，會重新刷新定時器的時間，直到leader掛掉，才會出現定時器歸零進行選舉leader節點
查閱資料
https://baijiahao.baidu.com/s?id=1650890231453975345&wfr=spider&for=pc
https://blog.csdn.net/qq_34802511/article/details/81296190
AKF：https://www.bilibili.com/video/BV1LA411e7Rv?p=7
Raft：https://blog.csdn.net/bjweimengshu/article/details/80222416