分布式系统原理系列目录
大家有没有注意到，在很多分布式工具的架构图中，zookeeper的出镜率很高，比如hdfs、Hbase、kafka、spark、TIDB，他们的架构图里面都有个zookeeper，zookeeper在其中承担的一个重要职责是分布式协调工作 比如说选举(就是在主从架构里，通过它选择Master，master挂了就再选一个，保证高可用)
那问题来了，如果把zk换成关系数据库可不可以？
比如要选举时大家都竞争数据库的同一把锁，谁拿到锁谁当leader，是不是也OK？
选举要保证两点：1.最终只能有一个节点当选领导；2.所有节点都要达成一致
看起来好像用数据库是可以满足的，由master来负责加锁，可以保证只有一个节点能加锁成功，之后其他节点也能看到谁加锁成功了，可以达成一致
问题是如果master挂了怎么办呢？还能保证上面说的两点吗？
你可能会说搞个主从架构，主节点挂了会重新选主，不就行了吗？问题是怎么选主呢？
我们看下面这张图，这是tdsql(分布式数据库)的架构图，你看它里面也有个zk，它就是依赖于zk帮他做选举，以保证自己的可用性的。所以说tdsql自己是不能保证自己的可用性的，它依赖于一个三方组件zk来保证自己的可用性
那zk的可用性又是怎么保证的？它有没有再去依赖一个三方的节点去保证自己的可用性呢？
没有！zk可以自己保证自己的可用性，怎么做到的呢？ 因为它实现了共识算法，他可以通过共识算法让多个节点选出一个leader，而且可以保证选举过程中，大家是可以达成一致的，即使遇到部分节点故障、网络异常等问题，也可以保证这个过程的一致性
那共识算法是什么？
好，我们把这个问题先放在这里，现在考虑下下面这个场景：
有个村里有一群人，一群平等的人，如果出现了一些关乎村子整体利益的事情，他们怎么做决策？有两种办法
1、大家投票选出一个村长，让这个村长去做决策
2、不选村长，每次来事都是大家投票决定
要想做决策，就只能是这两种方案，否则就没办法做决策，这个很好理解对吧。不可能说你不是村长，也不想参与投票，你就自己玩自己的，自己做决策，那大家都自行决策，到底谁说了算？
不管是大家投票选村长，还是不选村长每次都投票做决策，本质上都要解决一个问题，那就是多个节点要就一个事情达成共识，投票选村长就是大家就选村长这个事情达成共识，上面提到的tdsql多个节点选主，也需要大家就谁当leader这个问题达成共识
分布式系统跟单机系统的本质区别之一是，一个节点变成了多个节点，做决定时，一个节点说了不算，必须大家都同意才能算。比如一个拥有A、B、C三个节点的存储系统X，同一时刻，客户端1向A发送write x=1，客户端2向B发生write x=2，当X收到这两个请求后，x到底应该等于几呢？A觉得应该等于1，B觉得应该等于2，到底等于几呢？
再比如说，上面提到的选举问题，A选B当leader，B选C当leader，那谁来当leader呢？
所以说，从单机系统变成分布式系统后，带来了一个根本问题，就是共识问题，作为一个整体，分布式系统的多个节点必须达成共识，才能保证系统正常工作
如果没有理解的话，可以再看下上面tdSql架构图，如果不依赖于zk或者说zk底层的共识算法，tdSql就没办法保证可用性。因为matser挂了的时候，想要重新选master只有两个办法，一个就是从节点自己投票选，这个过程其实就是达成共识的过程，也是需要共识算法实现的。还有一种就是现在这样，依赖于一个中介节点(zk)去选举，那就引出一个套娃问题，zk自己的可用性又如何保证，还是需要一个共识算法
有了共识算法，zk就能自己保证自己的可用性，因为他可以让多个节点就选leader这个事情达成共识，之后就让这个Leader去提供写服务，如果leader挂了，就再发起一轮选举，如此保证自己的高可用。zk自己的高可用问题保证了，它才能给tdsql、hdfs、Hbase、kafka、spark、TIDB这类分布式系统重非常重要的基础设施提供分布式协调工作，保证这些基础设施的正常工作
而这一切的基础正是分布式共识算法！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
