试剂产品商城网站建设,杭州网站现场备案,网站怎么做响应,做网站设计挣钱吗本文分享和对比了 etcd 和 Consul 这两个存储的一致性读的实现。 作者#xff1a;戴岳兵#xff0c;爱可生研发中心工程师#xff0c;负责项目的需求开发与维护工作。 爱可生开源社区出品#xff0c;原创内容未经授权不得随意使用#xff0c;转载请联系小编并注明来源。 本…本文分享和对比了 etcd 和 Consul 这两个存储的一致性读的实现。 作者戴岳兵爱可生研发中心工程师负责项目的需求开发与维护工作。 爱可生开源社区出品原创内容未经授权不得随意使用转载请联系小编并注明来源。 本文约 900 字预计阅读需要 3 分钟。 etcd 和 Consul 是现在比较流行的分布式一致性 KV 存储本文就来分享和对比一下这两个存储的一致性读的实现。
Consul 一致性读的实现
Consul 有三种读模式
defaultconsistentstale
其中 stale 是非一致性的读模式而 default 和 consistent 是一致性的。
consistent 和 default 的区别在于 consistent 在读之前还会向各个节点确认自己是否还是 Leader以防止在读之前的一瞬间变为 Follower导致读取到旧值。
接下来我们看看具体实现的代码 在 Get 方法的一开始 Consul 就调用了 ForwardRPC 方法来转发 RPC 请求如果转发请求成功就直接返回。
如果转发请求没完成就会取调用 blockingQuery 来查询本地的存储返回结果。
我们再来看一下 ForwardRPC 内部的实现。 可以看到 ForwardRPC 方法内部主要做了三件事情
如果需要转发请求给其他 DC判断当前节点是否能处理这个读请求如果不能处理转发请求给 Leader
我们再来看看第 2 步 Consul 是如何判断的。 其中 info.IsRead 用来判断是不是一个读请求info.AllowStaleRead 判断 HTTP 请求参数中的 AllowStale为 false 时即为一致性的读请求而最后判断是否已经跟 Leader 交互过。
所以当一个请求是一致性读请求时就会走到第 3 步将请求转发到 Leader 上。 而在转发 Leader 时会判断自身是不是 Leader如果不是才会转发。
小结
从这几段逻辑可以看出Consul 的一致性读是通过转发读请求给 Leader 来实现的。
etcd 一致性读的实现
etcd 的读分为串行读Serialize和线性读Linearizable两种模式。其中线性读是一致性的读模式。
同样的我们来看下一致性读的实现 可以看到串行读和线性读的区别只是在串行读之前调用了 linearizableReadNotify 方法。 而 linearizableReadNotify 中也只是简单的给 s.readwaitc 发信号然后等待结果。
这个信号将会在 linearizableReadLoop 方法中处理。 可以看到 linearizableReadLoop 方法中通过 requestCurrentIndex 方法获得了一个叫做 confirmedIndex 的 index。
requestCurrentIndex 会向 Leader 节点发送 MsgReadIndex 消息以获取 Leader 节点当前提交的最新的 index。然后再用本地的 appliedIndex 和 confirmedIndex 进行对比如果本地已应用的 index 小于 confirmedIndex 则进行等待直到追上 confirmedIndex 才会调用 nr.notify 发送通知信号解除 linearizableReadNotify 的等待进行后续的串行读操作。
也就是说 etcd 在做一致性读时会先从 Leader 节点获取 Leader 节点当前最新的 commited index然后和本地的 applied index 进行对比等到本地应用的日志追上 Leader 时才进行后续的串行读操作。
总结
从实现上来说 Consul 的一致性读的实现更加简单直接但是可能会对 Leader 节点的性能造成一些影响。
而相对来说 etcd 的实现更加复杂但是讨巧也充分利用到了每个节点的资源。
