search

CodisLabs / codis

Proxy based Redis cluster solution supporting pipeline and scaling dynamically
MIT License
13.16k stars 2.69k forks source link

Codis3.1中协调器使用etcd的问题 #1137

Open XMAN-WOMBAT opened 7 years ago

XMAN-WOMBAT commented 7 years ago

1、Codis3.1中etcd作为协调器时是否可以考虑使用V3?v2在使用watch时会有丢失数据的风险

spinlock commented 7 years ago

虽然写了 Watch 有关的 API，但是实际上在代码里面并没有用到。目前只用了 etcd 很少的功能。

我不太清楚在 Ephemeral 节点上，v2 和 v3 有什么区别？如果没有的话，不升级是不是也 OK？

欢迎 PR。

XMAN-WOMBAT commented 7 years ago

etcd没有Ephemeral节点，不过etcd有设置key或者dir ttl超时时间，etcd的watch机制可以通过事件索引获取该key或者dir的变化，但是整个etcd集群只会存储1000条事件，这里存在一个时间窗口，可能会丢失事件。v3版本解决了这个问题。

spinlock commented 7 years ago

是的。现在的实现就是通过刷新 ttl 达到 ephemeral 的目的的。

所以，这么看来直接把 v2 升级成 v3 似乎不会有太大问题？因为我没有 etcd 测试环境，所以即便升级了，我也没有办法保证没有问题。需要你自己测试。

yangzhe1991 commented 7 years ago

按我的理解watch也不是丢数据只是丢事件吧，这个codis应该不怕，只要知道节点有变化并且能拿到最新版本就行，中间变了多次都跳过去也无所谓的。ZK在这个问题上也是一样的

XMAN-WOMBAT commented 7 years ago

@yangzhe1991 etcd 丢失watch事件意味着丢失该事件对应的数据，只是不会丢失该key所对应的最终数据

spinlock commented 7 years ago

跑偏了。 我记得 3.1 没用 watch 接口，现在的问题是，不想同时维护 v2 和 v3 对吧？

XMAN-WOMBAT commented 7 years ago

@spinlock haha,you are so beautiful。一语中的，O(∩_∩)O哈哈~

tangcong commented 7 years ago

如果升级到etcdv3 是 Flat key space 没有目录的概念。模拟一层目录可以用prefix匹配，但是二层，三层目录就有问题了吧。。集群多了一次prefix /codis3可能会获取上万个节点 不过加前缀可以模拟解决二层，三层等目录，加前缀又会引发兼容性问题，有更好的方案吗 @spinlock @XMAN-WOMBAT

spinlock commented 7 years ago

@tangcong thx!

etcdv3 的变化的确处理起来非常痛苦。其实 list 接口使用的情况非常少（只在 codis-fe 和 codis-dashboard 有少部分使用）。通过 prefix 去 scan 的话，其实压力应该不会太大。不过实现太丑了。

保留之前的多个结点的设计现在看来是多余的，而且这种实现的直接后果是代码写起来非常非常的复杂。不过我当初这么设计的出发点是希望使用 json + 减少写放大。不过显然过度设计了。

现在倾向于把单个集群的所有配置压缩成 pb + gzip 的格式，前提条件是能把压缩后的数据控制在几 KB 以内。不过如果这样的话，保存在 zk/etcd 上的数据格式又不兼容了。。不过好在只影响到 codis-dashboard，处理好格式升级的话（忽略降级）难度应该不大。

再考虑一下。

fancy-rabbit commented 7 years ago

https://github.com/coreos/zetcd/ 这个玩意可以把 etcdv3 模拟成一个 zookeeper 服务接口，用前缀匹配和限制深度来模拟列目录。

我们正在考虑一下是不是使用 etcdv3 + zetcd 的模式，codis 就当是去连 zookeeper.

spinlock commented 7 years ago

@fancy-rabbit 其实模拟不是问题。之所以升级 etcdv3 迟迟没有做，是因为事情 block 在了：

在 3.0 重构的时候，太过保守了，保留了层级结构，导致扩展上的各种问题。其实整个集群配置打包在一个 struct 里面，并 通过 gzip + gob 的方式进行压缩+组织，这样，目录树可以压缩成一个节点，压缩后节点在百 KB 内。虽然写放大比较严重，但是考虑到 rarely 的写，这种写放大还是可以接受的，收益是 etcd/zk 的接口变得会更简单，接入 etcd 也更容易了。

fancy-rabbit commented 7 years ago

写放大在3.2的场景下倒是不怎么有所谓 不会经常写。 只是proxy和zk解耦之后其实也用的挺好的，改成你说的这种形式意义貌似也并不十分的大？

On Jul 25, 2017 10:02, "spinlock" notifications@github.com wrote:

@fancy-rabbit https://github.com/fancy-rabbit 其实模拟不是问题。主要是我在 3.0 重构的时候，太过保守了，保留了层级结构，导致扩展上的各种问题。所以升级 etcdv3 迟迟没有做。因为我在想：

其实整个集群配置打包在一个 struct 里面，并 通过 gzip + gob 的方式进行压缩+组织，这样，目录树可以压缩成一个节点，压缩后节点在百 KB 内。虽然写放大比较严重，但是考虑到 rarely 的写，这种写放大还是可以接受的。

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CodisLabs/codis/issues/1137#issuecomment-317606701, or mute the thread https://github.com/notifications/unsubscribe-auth/AAazLH8sJUge09jbAT1Y3T37jleFP6lXks5sRUy8gaJpZM4L5CD8 .

yaoyinbear commented 5 years ago

所以这个问题到底结论如何？我看了好几遍，感觉结论是 Codis 3.2 + etcd 3.2 应该不会有什么问题