脑裂问题
HDFS 1.0 架构，图片取自：《Hadoop：The Definitive Guide》
1.0问题
- namenode单点问题
- 随着集群扩展，namenode管理文件元数据存在瓶颈
2.0解决方案
- 增加协调者（coordinator）管理一主多从的NameNode节点提供高可用的NameNode
- federation联邦解决方案，可以理解为分片方案类似于分库分表
脑裂问题（分区问题）
正常情况下的协调者
机房1与机房2出现网络故障后，机房2重新选举leader，导致脑裂问题如下。导致暴露两个leader同时处理读写请求，导致分区数据不一致问题
解决方案
选举法
著名的Paxos算法
引入“过半概念”，投票选举，只有通过过半数的赞成票才可以被选举为leader。那么网络故障导致的分区问题解决了，但是它的限制也很明显就是如果出现过半的机器宕机，会导致整个集群无法正常提供服务
RAFT算法
简单讲下选举的场景
选举超时时间：该时间为一个150ms至300ms之间的一个随机数
每个节点初始为无身份，在随机产生的选举超时时间结束后自身则会变成候选者，向其他节点发起投票选举自己为leader，如果其他节点此时还没有超时发起投票则选举在他自身之前醒来的候选者（即发起投票者发来的请求响应为投票给对方），并重置自身的选举超时时间。当某一个节点收到过半的投票支持者时，则更新自身身份，由候选者升级为leader。
心跳超时时间：leader会向其他follower节点发送心跳消息，如果超时未收到心跳信息，则重新选举leader，在自身选举超时后更新自身为候选者，逻辑同上面所说
为什么要维护两个超时时间呢？
如果没有心跳超时时间设置，那么节点一直处于选举状态，可能会频繁的发生leader切换，岂不是庸人自扰？
感兴趣的同学可以跳转到该文章了解详情，文章带着案例讲解，通俗易懂，很棒的文章：http://thesecretlivesofdata.com/raft/
冗余通信（Redundant communications）
顾名思义，冗余通信的方式来保证通信的高可用性，避免出现分区
隔离（fencing）
引入公共共享资源，第三方存储。例如：数据库（当然还可以选其他存储：redis、zk等）维护leader信息
- leader选举成功维护一条数据库数据，表明自身为leader，对该数据的读写以串行的方式保证并发安全性
- 如果follower与leader失联，尝试选举自身为leader，结果发现数据库中已经有leader存在
- 通过RPC、ssh等等方式执行已经存在的leader服务器上的方法终止老leader进程，如果成功则更新leader为自身
隔离的方式也采用了冗余通信的方式，如果远程终止leader进程的调用失败，则集群也会持续处于不可用状态
总结
- HDFS脑裂问题选用的为：隔离方案
- Zookeeper脑裂问题选用的为：选举法（过半概念），ZAB（zookeeper atomic broadcast）