@BBCCBB 理解 revision 后你会发现一个，多看看 waitDeletes 你会发现另外一个，看源码要有自己的理解

@BBCCBB 另外再补充一下，如果怀疑我说的，那么就动手实践，自己理解的更透彻，etcd 的大部分代码我都看过，而且还提过 pr，分布式锁和选主机制，在生产环境中都使用过，也做过多次测试，给到你的结论应该不会有问题的

@BBCCBB 就是这个代码，自己先弄懂几个 revision 的含义，还有个死循环，再对比一下网上某些实现，会发现官方的分布式锁帮你把各个方面的问题全部考虑到了，至少有两种情况使用场景中出现的概率几乎为 0，人家都帮你处理了。自己动手写个使用的 demo，你就会明白了，锁的机制：大家一起抢，谁抢到算谁的，其他人不停的在等待，锁释放了，剩下的人再继续抢。看代码要仔细看，不要轻易就下结论

@BBCCBB 我还真看过，你居然会说出 etcd clientv3 里的 mutex 是乐观锁，那么建议你再重新看看代码吧，记着是 golang 版本的客户端，etcd 版本 v3.3+

源码即文档，看一下 etcd go 的 clientv3 的代码不就行了么，官方都已经把你实现好了

11 年前，一张建行卡，我一直都不记得还在建行办理过储蓄卡，上个月因为转账需要去建行办卡，工作人员查到我有一张 11 年前的卡，直接在自助机上办理挂失，然后取号去柜台办理注销，里面还有 9 块钱还给了我，然后再去自助机上办理新卡，全程很方便的。

找人内推，抓住春招机会，修炼技术，踏实工作几年，多攒点钱，找个能买得起房的城市安家落户，目前不建议考虑户口问题，看看国家对户口的政策，北上广深基本不需要考虑，给你户口也白搭；二线城市落户只会越来越宽松，你只需要准备钱，没钱，没房，给你户口你能做什么？
现在有点迷茫不要紧，工作了忙起来就不会乱想了，应届生毕业焦虑综合征很普遍，多和家人沟通沟通。

看一下 nsq 的源码： https://github.com/nsqio/nsq/blob/master/nsqd/protocol_v2.go#L54
楼上很多人都说了，TCP 是流式协议，需要自己定义协议格式，然后按照协议去读取并解析。

@daocao 两垃圾

五菱宏光啊

不敢去牢厂，251 伺候

5. clientv3 里面有定时从 etcd 集群更新当前 etcd 集群可提供服务机器的代码 https://github.com/etcd-io/etcd/blob/master/clientv3/client.go#L193, 所以并不是你说的只要有一个存活就不影响程序运行，那么说明你的测试密度不够，客户端肯定不是实时响应服务端机器变化的

给你简单解释一下：
1. etcd 的通信是基于 grpc 的，grpc 每次非 stream 的请求，每次使用的 server 地址都可能不一样，详细看可以看 clientv3 的 balance 源码，看看 etcd 怎么做 grpc 连接的负载均衡的，记着是每次请求
2. etcd 是基于 raft 协议的，写请求会自动转到主，读请求（不包括非线性读）可以读从，线性读的机制比较复杂，你可以认为是主节点响应的（这里比较复杂，建议看源码）
3. raft 集群，如果主挂掉，那么其他机器会自动选主，所以你说的一台机器挂掉是不影响 etcd 的使用的，当挂掉的机器恢复后，会变成从机，然后从主机同步数据
4. etcd golang clientv3 连接 etcd servers 的代码相对来说比较简单，很容易看懂，但想要完整的理解全套逻辑，需要看 server 的部分代码，raft 部分基本上不需要看，只需要理解 raft 协议本身即可

进销存管理系统，spring 全家桶，mybatis+mysql

beego 框架根本就不适合 golang 的开发模式好不啦，换 gin，真香

来来来，我给你写个，外包 10W，保证全网最快，不保证正确