很多初学者错误地认为, 像 Raft 这样的 leader based 的分布式协议不是 100% 高可用的, 因为"Raft 在选主的过程中, 不能提供服务". 初学者之所以存在这种错误认知, 完全是因为他们没有理论结合实践, 只略懂一点理论皮毛, 就胡乱引申导致的. 本文将在理论和实践结合的层面上, 分析这种错误认知.
首先, Raft 的选举过程并没有特殊的成本, 在局域网条件下, 一般只需要 5ms 的时间. 5 毫秒对于实用的分布式集群, 是微不足道的时间长度, 因为客户端对时间长度的认知是百毫秒级别的, 只要客户端在 5 毫秒之后重试[可靠通信三原则], 或者服务器先 Hold 住请求, 过 5 毫秒之后再处理, 对于客户端来说, 完全没有感受到服务不可用, 因此, 服务是 100% 高可用.
我认为, leader based 的集群, 最大的问题在于"何时发起选举?". 也就是, 如何能快速地发现当前集群失去了有效的 leader.
客户端可能发现集群无主, 但是, 我们不会把这个权限赋予客户端, 因为在 CS 理论中, 客户端是不可信的. 所以, 只能交由集群成员去发现集群是否需要发起选举.
那么, 集群成员如何判断和发现需要发起选举呢?
频繁地进行心跳探活交互是一种解决方案. 集群成员每隔一段时间, 就与其它全部成员交互, 以探测判断是否需要选举. 间隔的时间长短会累加到选举过程的 5ms 之上, 所以, 这个间隔不能太长, 太长如果超过客户端对时间的认知长度(百毫秒级别), 就会被客户端判定为服务不可用.
对于一个持续处理大量请求的集群来说, 由于集群处理请求过程本身就需要通信交互, 所以, 可以把心跳包附加到正常的交互报文之中. 但是, 对于一个空闲的集群来说, 大量的心跳探活交互, 造成了资源的浪费.
仔细分析 Paxos, 会发现"Paxos 在每一次请求处理流程中都进行选主"这个隐含的事实. 所以, 我们也可以借鉴 Paxos, 只在必要的时候才发起探活交互.
我们继续分析 leader based 的集群的特点. 在网络分区或者原 leader 宕机的场景下, 客户端应该怎么办? 直接拒绝服务? 不可能, 拒绝服务就不是 100% 高可用了. 所以, 即使客户端无法找到 leader, 也要强制地发起请求, 这时, 当然只能随机(或者按某种约定的规则)去请求某个 follower.
按照浅薄的理解, follower 不能处理请求. 但是, "follower 不能处理请求", 只是错误的静止的认知, 从动态发展的视角去看待问题, 如果 follower 转变成了 leader, 那么它当然就能处理请求. 什么? follower 每次收到请求, 就要发起选举? 事情肯定不会这样简单.
Follower 收到请求后, 它面临两个问题:
- 客户端发来这个请求, 是不是因为客户端有错误的认知?(客户端的路由表失效)
- 客户端发现集群需要选主?
如果是客户端自己的路由表失效, 那么回复一个 redirect 信息, 让客户端更新路由表即可, 之后一切回归正常. 如果是集群需要选主呢? Follower 当然不能轻信客户端, 它需要自己做判断.
Follower 有两种选择:
- 把请求 proxy 给自己所知道的 leader, 如果一切正常, follower 收到响应, 再转交给客户端
- 如果 leader 确实失效, 那就需要发起选举
无论何种选择, follower 都要面对如何判断是否需要选主的问题.
由于 follower 收到了请求, 从而触发了探活条件, follower 主动地发起一次探活流程, 以决定是否需要发起选举. 探活流程非常简单, 也很快速, 毫秒级别, 然后发起选举, 也是毫秒级别. 两套流程下来, follower 成为 leader, 然后处理请求, 返回响应. 如果不需要选举, 则 proxy 请求, 或者 redirect 让客户端刷新路由表重试. 这样, 对于客户端来说, 每一个请求都能被处理, 集群 100% 高可用, no problem.
所以, leader based 的集群和 100% 高可用有任何冲突吗? 完全没有! 为什么会有那么多人有似是而非的结论呢? 还不是只看了点皮毛理论, 思考太少, 实践不足, 妄想太多.
Loading ...