今天这篇文章赚到了
1.分布式选举算法是为了保证数据一致性的
在集群中存在多个节点提供服务，如果每个节点都可以写数据，这样容易造成数据的不一致，所以需要选举一个leader，往leader节点中写数据，然后同步到follower节点中。这样就能更好的保证一致性
但因为同步数据存在延迟，所以follower节点的数据不是每时每刻都和leader节点数据保持一致的
有的框架是由leader提供读写操作，这样能保证写和读都是最新的数据，我没记错的话kafka就属于这种，读写都发生在主副本上。
而像mysql集群是在主节点写入数据，从节点提供读功能，即主从架构

总之，我觉得，一个好的分布式选举算法能更好的保证数据的一致性

2.老师说的集群中存在双主是说选举算法出了问题，出现了两个主，还是说双主是正常情况，两个主互提供写服务，然后再互相同步数据的情况呢？

1、分布式选举和一致性的关系是什么？
个人理解选举本身其实就是一致性的一次协商，要求全局认可同一个节点做主节点。选举的目的是为了简化一致性协商的流程，让选出的master来协调各成员针对某项决议达成一致；
2、你是否见到过一个集群中存在双主的场景？
双主是可能发生的，例如原主网络与外部中断，集群发生脑裂，则老的集群主还存在，分裂的剩余节点由于与老主失联，大家重新选了新主出来。此时就会产生双主。规避双主的影响，需要通过租约机制，让老主发现在租约到期后与大多数节点失联主动降备；新主的选举也要等待超过这个租约时间后去选举新主，避免业务同一时刻看到双主。但是由于各个服务器资源、负载、调度等问题，时间并不是一个精确的可靠保障，例如定时器失真，还是可能导致同一时刻出现双主，所以每个地方的租约时间配置是个技术点。另外新主产生，生成新的epoch（+1），这样可以避免大家去处理老消息，从而进一步规避双主的问题。

分布式技术原理与算法#Day7
前几天我们看到了分布式集群中都会有一个协调者存在，比如那个厕所叫号员就是这么个角色。那究竟是谁能来做这个协调者或者管理者呢？选出这个负责协调和管理的主节点的过程就是分布式选举。同样我们前面也提到过多次的单点问题，很多时候就是领导者“驾崩”导致的，如何在领导者驾崩后立即再次选出下一任领导者，也是分布式选举中需要十分关注的一个点。
选主的常见原则是基于序号以及基于投票。类似资历优先（岁数大）还是能力优先（票数高）。
基于资历（序号）的常见算法就是Bully（恶霸）算法：就是选取所有节点中，ID最大的节点作为主节点。
既然需要判断自己是不是最大，就需要自己来存储其他所有节点的ID。选举开始后：
1. 宣誓主权：判断自己是不是最大的，如果是就通知各位自己是主了（向所有人发送Victory消息）
2. 认怂：如果自己不是最大的，需要向比自己大的认怂，承认各位大佬江湖地位，并等待回复（向大佬们发送Election）
3. 大佬收到小弟发来的Election消息，就会给小弟发送Alive，表示自己活着。（向小弟发送Alive信息）/
4. 小弟如果没有收到大佬发来的Alive信息，说明比自己大的都死绝了，我可以登基了（向所有人发送Victory消息）
可见其选举速度快、复杂度低、简单易实现。
但所有节点的信息存了所有其他节点的ID，存储的冗余度较高。而且有一个风险，就是ID最大的频繁进出集群，就会频繁切换主节点。还有一个缺点没提到就是ID最大的并不一定是能力最强的。
基于能力，民主一点的可以是Raft算法：核心思想是”少数服从多数“。
Raft算法规定了包括Leader主节点、Candidate 候选节点以及Follower跟随节点：
1. 开始选举时，大家都会变成候选节点，向其他节点发送选举请求
2. 每个节点根据先后顺序回复是否同意
3. 若同意数超过一半，则成为主节点，其他节点降为跟随节点，并与主节点互发心跳包
4. 主节点失效活着任期结束再来一轮选举
可见这种方式选举速度快、复杂度低、易于实现。
但选举时的通信量是n * (n -1 )。Raft如果ID最大的频繁进出集群，虽然会触发选主，但不一定真正切主。除非得票数过半。
基于能力，还有一种算法是ZAB算法：核心思想是“少数服从多数+ID大的优先”
ZAB是ZK实现协调所设计的。偏向于数据更新的节点。ZAB添加了server_zxID 来表示本节点存放的数据ID，越大越新（能力越强）。选举过程与Raft算法类似，只不过Raft根据先后顺序来判断，而ZAB先比较数据ID，数据ID相同的再比较ServerID，也就是说ZAB喜欢“能力强的年轻人”。
但同样也有广播风暴的问题，且增加了一点选举的复杂度，但会使得主节点更加稳定，因为新节点增加或故障节点（数据不会太新）恢复，触发选举后切主的可能性要更小一些。
因此你看后两种投票少数服从多数的情况下，最好还必须候选者是单数，否则可能因为票数相同而需要多次重新投票。所以经常看到ZK、etcd、K8S都会建议奇数节点。

打卡文章学习：
1、选主意义：主节点负责其他节点的协调和管理，保证其他节点有序的运行。
2、选举算法：
   (1).Bully算法,选择ID最大的节点作为主节点。需要用到3种消息：Election消息用于发起选举;Alive消息对Election消息的应答；

Victory消息，宣誓主权。优点：选举速度快、算法复杂度低、实现简单。缺点：每个节点需要有全局的节点信息，额外存储的信息较多；有

频繁切主的风险。
   (2).Raft算法,民主投票，少数服从多数。3种角色：Leader,Candidate,Follower。优点：选举速度快、算法复杂度低、易于实现。缺点:要求集群中每个节点都可以互相通信，且需要获取超过半数的投票才能选主成功，通信量大。
   (3).ZAB算法,具有优先级的民主投票，尽可能保证数据最新性,ID大的节点优先成为主。3种角色：Leader，Follower，Observer。4种状态：Looking,Leading,Following,Observing。。。每个节点有三元组(server_Id,server_zxID,epoch)。。。选主原则：server_zxID最大者成为Leader,若server_zxID相同，则server_id最大者成为Leader。优点：性能稳定。缺点：选举时间较长，容易出现广播风暴，需要知道所有节点的zxId和serverId，选举时间较长。

1.分布式选举和一致性，感觉是密不可分的。重新选举依靠一致性提供的数据，一致性又要依靠选举出来的主节点进行。这里我只了解过raft算法
https://www.cnblogs.com/xybaby/p/10124083.html
2.有个brain split（脑裂），比如说两个机房原来网络想通，可以正确选主，后来网络不通，每个机房都只知道自己的小山头，他们就容易各自占山为王。
http://www.ruanyifeng.com/blog/2018/07/cap.html
也可以搜下维基百科brain split。

在地铁上写的，有不对之处，请老师指出

老师：关于raft协议，之前看文章中有说raft协议也会保证拥有最多信息的节点在选举中优先获胜，这个文章中没有提及。
拥有最新的已提交的log entry的Follower才有资格成为Leader。
这个保证是在RequestVote RPC中做的，Candidate在发送RequestVote RPC时，要带上自己的最后一条日志的term和log index，其他节点收到消息时，如果发现自己的日志比请求中携带的更新，则拒绝投票。日志比较的原则是，如果本地的最后一条log entry的term更大，则term大的更新，如果term一样大，则log index更大的更新。
参考链接：https://zhuanlan.zhihu.com/p/32052223