raft 算法分享
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：
