技术分享 | etcd 与 Consul 的一致性读对比

外向笑小鸭子 2024-01-02 10:30:45  48090

分类专栏：资讯

etcd^[1] 和 Consul^[2] 是现在比较流行的分布式一致性 KV 存储，本文就来分享和对比一下这两个存储的一致性读的实现。

1Consul 一致性读的实现

Consul 有三种读模式：

default
consistent
stale

其中 stale 是非一致性的读模式，而 default 和 consistent 是一致性的。

consistent 和 default 的区别在于 consistent 在读之前还会向各个节点确认自己是否还是 Leader，以防止在读之前的一瞬间变为 Follower，导致读取到旧值。

接下来我们看看具体实现的代码：

etcd^[1] 和 Consul^[2] 是现在比较流行的分布式一致性 KV 存储，本文就来分享和对比一下这两个存储的一致性读的实现。

1Consul 一致性读的实现

Consul 有三种读模式：

default
consistent
stale

其中 stale 是非一致性的读模式，而 default 和 consistent 是一致性的。

consistent 和 default 的区别在于 consistent 在读之前还会向各个节点确认自己是否还是 Leader，以防止在读之前的一瞬间变为 Follower，导致读取到旧值。

接下来我们看看具体实现的代码：

小结

从这几段逻辑可以看出，Consul 的一致性读是通过转发读请求给 Leader 来实现的。

2etcd 一致性读的实现

etcd 的读分为串行读（Serialize）和线性读（Linearizable）两种模式。其中线性读是一致性的读模式。

同样的我们来看下一致性读的实现：

而 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 时，才进行后续的串行读操作。

3总结

从实现上来说 Consul 的一致性读的实现更加简单直接，但是可能会对 Leader 节点的性能造成一些影响。

而相对来说 etcd 的实现更加复杂但是讨巧，也充分利用到了每个节点的资源。

参考资料

[1]

etcd: https://etcd.io/

[2]

Cousul: https://www.consul.io/

本文关键字：#ectd# #Consul# #源码#

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接： http://www.xckfsq.com/news/show.html?id=34090

赞同 0

评论 0 条

技术分享 | etcd 与 Consul 的一致性读对比

1Consul 一致性读的实现

1Consul 一致性读的实现

小结

2etcd 一致性读的实现

3总结

参考资料

相关文章

关注我们