有没有办法实现简单的 Go 服务 leader 选举？

[teli]

需要从服务实例中选出一个 leader ，从事一些必须“全局唯一”的事情。

当 leader 因为各种原因下线后，其它实例要能及时选举出新 leader 。

要求依赖别太重，或者依赖常用组件服务，比如 redis 。还要考虑这个依赖的组件服务可能掉线可能重连。

[Juszoe]

https://github.com/hashicorp/raft

[BBCCBB]

别听楼上什么分布式锁 redis 几行代码就搞定了,

要是其他方案靠谱的话, 就不会有 paxos, raft 了

[my3157]

@teli 知道那些节点在线，那些不在线，上 /下线都有 event ，节点之间还可以广播数据，选个主还不简单，说个最 low 的方法，获取当前活着的节点列表，把 peer ip + port 转成 int ，选最小活着最大的

[dusu]

我这边项目选 leader 主要是为了节点挂了服务正常
所以 redis 的 ping 锁操作可以
但是不适应于异地集群
而且也有单点问题
目前我的简单的解决方案：
用 cloudflare 的 kv 服务代替 redis 使用

[misaka19000]

直接 redis 分布式锁啊，redis 用哨兵实现高可用就行了

[joesonw]

redis setnx 。slave 到 master 断了再去抢，其余的没抢到的直接取值找到 master 是谁。

[SeaTac]

我们用的是改过的 paxos
3 个 replica ，1 leader 2 follower
但是实现挺复杂的

[rrfeng]

最简单的肯定是借助现有的依赖啊，比如你用了数据库，那就在数据库里搞一条记录，所有实例来抢占就行了。
Redis 也行，有啥用啥。

[defage]

我记得 etcd 有个嵌入的 lib 可以直接用，不是自己部署 etcd 服务，是自己用它的 sdk

[GTim]

@ikaros 最佳方案，没有之一

[teli]

@defage https://pkg.go.dev/github.com/coreos/etcd/embed
这个？

[xsen]

@teli #31 你那个好像有些问题的，这个是可以，
https://pkg.go.dev/go.etcd.io/etcd/server/v3/embed

[litguy]

etcd 的锁机制就可以完成你的功能
几年前我们就是基于这个作的

[sujin190]

既然如此，直接实现成分布式锁的逻辑就是了呗，谁获取锁成功谁就能操作或者是 leader

[solos]

https://github.com/lni/dragonboat

[evil0harry]

@okayan 404

[clownpiece]

如果 redis 集群出现故障导致你们 leader 选举出现问题如重复或者无 leader ，那是你们团队的锅，因为 redis 不提供保证。如果用 zk 或者 etcd 出现问题，是对应组件 dba 的锅。
所以选什么很明显了

[starqoq]

西方的选举制度可能不适合我们中国的程序呢。建议程序们开一个党代会选出全局唯一的核心。狗头。

[ihciah]

redis 选主没什么问题，简单方便，还不要求节点之间的连通性。
raft/etcd 杀鸡用牛刀了，你说它能用吧，它确实能用。为啥 etcd 不用 redis ？因为 redis 是单机服务，而 etcd 想解决的就是单点故障。只要你保证 redis 不宕机，那走 redis 就是个 ok 的方案。生产环境不少就是这么选主的，业务自个用 raft 的倒是一个没见过。

[xingjue]

@starqoq 还要考虑 做到两个维护