mysql 分享
參考
mysql講義
mysql acid的設計實現
raft 算法分享 （|| paxos）
分佈式 raft 算法
https://zhuanlan.51cto.com/art/201910/604122.htm
深入淺出Paxos
https://cloud.tencent.com/developer/article/1380841
https://www.bilibili.com/video/a
v61558449?p=3
https://www.bilibili.com/video/av21667358?from=search&seid=402974514119071173
https://zh.wikipedia.org/wiki/Raft
http://thesecretlivesofdata.com/raft/
https://cloud.tencent.com/developer/article/1477205
https://raft.github.io/
https://blog.csdn.net/niuniuasb/article/details/54798932
https://lotabout.me/2019/Raft-Consensus-Algorithm/
https://www.infoq.cn/article/building-flexible-storage-system-based-on-raft
https://www.infoq.cn/article/2018/03/Baidu-open-source-Raft-algorithm
https://blog.csdn.net/longxibendi/article/details/43340469
raft vs zab
投票上：
raft只能投一票，zab可以投多票
日誌複製：
raft 通過心跳逐漸的複製， zab 在選舉出leader後專門的去複製數據
數據讀取：
raft 在第一次和leader建立連接後，以後都通過leader。zab 就只轉發寫的請求，讀就從節點就處理了
檢測leader宕機：
raft 通過從 leader 到 follower 的單項心跳來判斷 ， zab進行雙向的判斷：leader自己有個和自己保持連接集合，不到一半時就放棄leader身份，follower 也有向leader的超鏈接
建立連接的方式：
raft 發出兩種請求是要等待回覆，超時就重試。 而 zab 就廣播出去就行了
--------------------------------------------------------------------------------
zookeeper 做註冊中心有哪些弊端：
1、zk 使用 zab 協議保證一致性，註冊中心如果追求可用性，有一個總比沒有好時，是個弊端
2、不適合大規模頻繁註冊寫的問題，它保證數據的一致性和持久性（zookeeper 的特長是做分佈式協調服務），毫秒級的服務健康檢測，服務保持長連接，寫不可擴展
3、當發生網絡分區時，zk 爲了保證腦裂下數據一致性，放棄了可用性
4、在粗粒度分佈式鎖，分佈式選主，主備高可用切換等不需要高TPS 支持的場景下有不可替代的作用
http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/
我分享的ppt：