Coder2021-02-15精彩，总体上获得以下收获: 1. 基础篇知识学以致用，问题定位、分析思路 2. 不一致bug原因，复制状态机模式的问题，应用日志条目到状态机时，因etcd里面含有各种业务逻辑，无法保证各个节点都成功 3. 了解几个常见不一致的bug， 这个老师能给下详细的github issue、pr地址，还需要深入消化小才能彻底搞懂 4. 最佳实践干货满满，感受到了老师在这块的丰富经验，我感觉监控key数挺好用的，也简单，数据安全是红线，定时备份太重要了，否则遇到老师说的数据不一致bug，就欲哭无泪了作者回复: 赞，有收获就好，总结到位，地址我给下： https://github.com/etcd-io/etcd/issues/11651 https://github.com/etcd-io/etcd/pull/11613 https://github.com/etcd-io/etcd/issues/11689
9
yangf2021-02-18在项目中大量使用了 etcd，这里介绍两个曾经遇到的问题。 1. 使用 etcd watch，在 go watch client 中出现大量内存堆积的问题，一度怀疑是 etcd lib 的问题，深入定位后发现是从 watch channel 中消费速度小于 key 变更速度导致。（在我的个人博客里记录了这个问题：https://amyangfei.me/2020/12/19/best-practice-with-go-etcd/#Consume-data-from-the-watch-response-channel-ASAP ） 2. 使用 etcd lease 的一系列问题，包括 concurrency 包提供的 `session.Done` 通知存在延迟问题，etcd lease 删除 key 也存在的延迟删除问题。（个人博客里还有一篇文章对 lease 的一些实现原理和使用注意点做了分析：https://amyangfei.me/2020/12/27/thinking-about-etcd-lease/） 遇到 etcd 使用问题经常搜索，还见到过唐老师提的 issue/pr :-)作者回复: 赞，优秀，总结得挺好，watch这个案例我觉得可以给社区提个PR，在Watch API增加下说明，lease的实现的确会导致删除key存在延迟，甚至在高负载、磁盘IO异常等情况下会导致old leader也会触发撤销lease操作。
共 3 条评论8
春风2021-02-22老师，leader需要法定人数，脑裂在什么情况下发生呢作者回复: 如果出现网络分区故障，旧的leader和集群其他节点出现了网络隔离，其他节点选出了新leader，旧的leader也没有感知到新leader, 这时会出现短暂双leader。如果使用的串行读，那么旧的leader也能提供读取数据，线性读因需要获取集群共识数据，因此是无法读取的，旧的leader也是无法写入的。 严格意义上来说，这种情况不能称之为脑裂，就目前来说，如果不存在任何未知的bug, 基于Raft共识算法实现的etcd, 是可以防止脑裂发生的。
共 2 条评论2
shp2021-08-02请问老师，每隔30分钟备份一次，如果需要使用备份恢复数据，那么在备份后到使用备份恢复前这段时间的数据操作是不是会全部丢失，还是有什么方法只恢复损坏的数据？作者回复: 是的，会丢失数据，备份可缩短到3-10分钟一次，etcd 3.5已经支持在learner节点上进行备份，对读写性能不会有任何影响，如果想恢复损害的数据要看具体情况了（比如什么bug触发的、是否某个节点有完整数据、业务client是否有打印写请求日志等），操作起来有不少复杂度，自从我文中所列的几个可能导致不一致bug被修复后，最近一年多社区已经没有报任何不一致的问题啦，如果担心不一致，可升级到3.4较新版本。
1
写点啥呢2021-02-15请教唐老师，04节内容中介绍etcd写请求流程中涉及到多个log，不稳定raft log->wal -> 稳定raft log，能不能请老师进一步介绍下这三个日志的用处和关系呢？特别是在涉及到节点崩溃数据恢复时候这几个日志是如何配合恢复数据的？ 谢谢老师作者回复: 好的，等我忙完专栏目录计划的内容，答疑篇预计会增加一篇etcd启动后发生了什么，可以在这篇里面，增加相关内容，稍等哈
1
yybear2021-10-08获取各个节点的 revision 和 boltdb hash 值，若出现 Follower 节点的 revision 大于 Leader 等异常情况时，就可以认为不一致 --------------------------------- revision 是apply时递增的，如果follower的apply处理速度大于Leader 的速度，是存在Follower 节点的 revision 大于 Leader的情况吧？