分布式系统原理系列目录
为什么很多分布式工具中都有个zk,换成关系型数据库可以吗?
大家经常看到各种分布式工具的架构图中都有个zookeeper(比如hdfs、Hbase、kafka),然后它们的架构说明里都会说zk承担保存元数据和协调工作。这里的协调工作中的一个核心任务就是指选举(就是在主从架构里,通过它选择Master,master挂了就再选一个,保证高可用),那问题来了,如果把zk换成关系数据库可不可以?比如要选举时大家都往数据库插入一条数据,谁成功谁当leader
咋一看好像可以是不是,问题是关系型数据库一般都是主从架构的,主节点挂了怎么办?或者说它自己的可用性如何保证?你可能会说重新选主啊,问题是怎么选主呢
关系型数据库的可用性如何保证?依赖于中介节点,比如zk
我们看下面这张图,这是tdsql(基于mysql)的架构图,你看它里面也有个zk,它就是依赖于zk保证高可用的
不过tdsql的主从不是直接通过zk选的,是间接依赖的,主从切换过程我大概说下:
每台mysql节点上都有一个agent进程,agent会定时向这个schduler上报mysql的状态,如果schduler发现matser的状态有问题,就会把这个主节点降级成Slave。此时整个集群里面全是Slave,没有master。这个时候两个slave会通过agent把自己自己最新的binlog点上报给Scheduler,谁的数据更新,Scheduler就会把它提升为master。这个过程是不依赖于zk的,但是这里有个套娃问题就是主从mysql依赖于scheduler保证可用性,那Scheduler的可用性谁来保证呢?答案就是zk
为什么zk可以自己保证自己的可用性?分布式共识算法
那zk有没有再去依赖一个三方的节点去保证自己的可用性呢?没有,它可以自己保证自己的可用性呢?为啥呢?因为他有共识算法,他可以通过共识算法自行选出leader,leader挂了再选一个,只要有半数节点活跃,他就一直可用。那共识算法是什么?好,我们把这个问题先放在这里
一群平等的人,如何完成决策?
现在考虑下现实生活场景,世界最初的状态一定是大家都平等的,比如有个村里有一群人,平等的人,这个时候如果出现了一些关乎村子整体利益的事情,他们怎么做决策?一般来说有两种方案
- 一种是大家投票选出一个村长,让这个村长去做决策,村长跪了就重新选
- 还有一种是不选村长,每次来事都是大家投票决定
要想做决策,就只能是这两种方案,否则就没办法做决策,这个很好理解对吧。不可能说你不是村长,也不想参与投票,你就自己玩自己的,自己做决策,那大家都自行决策,到底谁说了算?
不管是大家投票选村长,还是不选村长每次都投票做决策,本质上都要解决一个问题,那就是多个平等的节点要就一个事情达成共识,投票选村长就是大家就选村长这个事情达成共识,那让多个节点达成共识的算法就叫做分布式共识算法
所以说我们一定需要一个分布式共识算法
这样论证不知道大家有没有理解哦,可以再看下上面tdSql架构图,论点是如果不依赖于zk或者说zk底层的共识算法,tdSql就没办法保证可用性。因为matser挂了的时候,想要重新选master只有两个办法,一个就是从节点自己投票选,这个过程其实就是达成共识的过程,也是需要共识算法实现的。还有一种就是现在这样,依赖于一个中介节点(zk)去选举,那就引出一个套娃问题,zk自己的可用性又如何保证,还是需要一个共识算法
好,有了共识算法,zk就能自己保证自己的可用性,因为他可以让多个节点就选leader这个事情达成共识,之后就让这个Leader去提供写服务,如果leader挂了,就再发起一轮选举
我们这里只说了zk的共识算法,其实zk还提供了一些其他的有用的功能,像存储数据这个不用多说了,它本身就是个存储系统,再比如分布式锁、数据发布订阅(比如有些公司就用zk来实现配置中心,配置中心就有个功能是配置变更后回调应用程序),心跳检测(他可以帮你检测节点是否活跃,省了自己各个节点间互相通过心跳包去探测,耦合度比较高,而且还不一定可靠)
这些功能都非常好用,但其底层大多都是由共识算法支撑的,共识算法是核心中的核心,接下来我们就具体看看共识算法