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

发布于 1周前 作者 wuwangju 来自 Go语言

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

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

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


有没有办法实现简单的 Golang Go语言服务 leader 选举？
Harmonyos Next教程
49 回复

如果是在 kubernetes 集群里的话，可以直接用 k8s.io/client-go/tools/leaderelection

更多关于有没有办法实现简单的 Golang Go语言服务 leader 选举？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


好像记得 zookeeper 也有这个功能吧

基于 raft 写个状态机，不过感觉有点杀鸡用牛刀 https://github.com/hashicorp/raft

可能没 zookeeper 这个或这类组件。
但 redis 应该都有

不想要有重的外部依赖的话，自己现实的工作量也会很重哦。感觉这个开发成本并不一定比外部组件的维护成本低。我记得早期 kafka 的选主也是依赖 zookeeper 来实现的。后来才去掉了。

需求不是特别严格的话不难，比如找一个基于数据库或者 redis 的锁的库就行，但是会有一些细节上的问题，比如 redis 可能是单点，要是用集群的话，数据同步可能有延迟，一些极端情况下可能还是不可用或者出现竞争等。

zookeeper 算常用组件了吧, 用这个就可以呀

redis 原子操作 put 一个 value 为节点的 IP, 然后配置 key 15 秒过期. 5 秒维持一次过期时间.

value 为节点 IP 的就是 leader, leader 挂了之后 15 秒之后 put 成功的就是下一个 leader

embedded etcd

leader 这东西类似于分布式锁，可以看看按照分布式锁的思路来做。每个实例起一个后台线程，定时去尝试获取分布式锁。对于获取锁成功的那个实例就是 leader ，然后定时去刷新过期时间。如果 leader 挂了，那么其他实例获得分布式锁的就是 leader 了

这个方案貌似不错。
不知道资源消耗多少？有实例代码吗？

可否对「“全局唯一”的事情」举个例子？我是觉得常见业务不用 leader 选举也能做到独占，leader 选举这样的设计一般是为了保证同步

https://github.com/hashicorp/memberlist

目前需求是全局只有一个实例在干这事

raft + 1 ，可以看一下 mit 的 6.824 ，就是用 raft 写的一个分布式 kv 服务

结合 10L 可以用 redis 分布式锁，按一定周期获取锁

看起来很牛掰。但没发现支持 leader 特性。有什么好办法基于这个实现 leader 选举吗？

我首先想到的也是这个办法。但上面有位朋友提醒了我，如果是集群，同步会有延迟。这个有什么好应对办法？

为啥不考虑锁，而去搞个选举。选举要考虑各种情况的脑裂，问题一大堆。分布式锁 redis 几行代码就搞定了

https://pdos.csail.mit.edu/6.824/labs/lab-raft.html

https://github.com/hashicorp/raft

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

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

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

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

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

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

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

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

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

最佳方案，没有之一

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

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

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

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

https://github.com/lni/dragonboat

404

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

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

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

还要考虑 做到两个维护

zookeeper 完事，别给自己找不愉快

Redis vs Etcd vs memberlist vs paxos ，m

https://github.com/kubernetes/client-go/tree/master/tools/leaderelection

暂定是 docker swarm ，而非 kubernetes

https://pkg.go.dev/go.etcd.io/etcd/clientv3/concurrency#Election.Campaign

麻了现在 golang 看上去很火，怎么看评论好像没啥真正在用的

楼上提 redis 的是怎么搞的，和在 go 里面用一个锁有什么区别？

一般是集群每台都尝试去做，但是拿到锁的那台再去做，这个都不要求主备一致性的，有啥必要上 paxos 和 raft 这种？

用 consul 抢占 session 就行了。

在Golang中实现简单的服务leader选举，可以采用多种方法，其中一种常见且高效的方法是使用分布式锁服务（如Etcd、Consul等）或者Raft一致性算法库。这里提供一个基于Etcd的简单实现思路：

  1. 使用Etcd作为分布式锁服务：

    • 首先，所有候选服务实例都尝试在Etcd中创建一个具有相同键和较短租约（lease）的锁。
    • 成功创建锁的服务实例将成为leader，并定期进行心跳（renew lease）以保持锁的有效性。
    • 如果leader服务实例崩溃或失去与Etcd的连接，锁将自动释放，其他候选服务实例将检测到这一变化并尝试重新获取锁，从而触发新的leader选举。

  2. 使用Raft一致性算法库：

    • 引入Raft库（如etcd-io/etcd/raft或hashicorp/raft）到您的Golang项目中。
    • 配置并启动Raft节点，每个服务实例作为一个节点加入集群。
    • 通过Raft的选举机制自动确定leader节点。
    • 选举出的leader节点可以负责处理特定的服务请求或协调任务。

这两种方法都提供了高可用性和容错性，适用于分布式系统中的leader选举场景。选择哪种方法取决于您的具体需求，如系统的复杂性、对一致性的要求以及是否愿意引入额外的依赖等。对于简单的leader选举需求，使用Etcd作为分布式锁服务可能是一个更快速且易于实现的解决方案。

回到顶部