准备基于 redis 写个简单的集群 leader 选举，大家帮忙看看方案

[wencan]

我对分布式和 redis 了解有限，所以还清大家帮忙看看。

服务启动时，每个实例尝试对 key 加锁，加锁成功的成为 leader 。加锁办法为 lua 脚本。有更好的加锁办法，请推荐。 leader 实例退出时，解锁，pub 消息通知其它实例，其它实例开始尝试加锁。 锁有超时时间，每次超时时间过半，leader 给 key 续时。如果 leader 非正常原因挂掉，key 会超时。 其它实例间隔随机时间尝试加锁， 或者收到 leader 退出消息时也尝试加锁，加锁成功的成为 leader 。

[leonme]

相比于 raft 协议的优势在哪儿？

[detached]

楼上灵魂拷问了，你的 motivation 在哪里，你的 novelty 在哪里 hhhh

[Cola98]

多个实例都尝试做加锁的时候怎么解决？

[morty0]

网络分区的情况怎么考虑

[sujin190]

@morty0 redis 只能单主的，不存在网络分区问题吧，网络分区后 redis 在哪个区只有哪个区能用，都不在就都不能用

[ql562482472]

@detached 现在越来越觉得这非常重要，做事有逻辑，有出发点，有落地点 怪不得以前进不去大厂 小厂自嗨的看多了 还真的能理解这些了

[rrfeng]

不错，现实中如果已经依赖了 Redis 这是个很简单有效的解决方案。相同方案也可以使用 MySQL ，或者其他任何支持 cap/事务的共享存储上。

说 raft 的，为了这么个破功能部署一套 etcd ？呵呵。

[djoiwhud]

@detached
不想为了一个 leader 选举需求搞出一堆全家桶。这个理由足够充分了。

[hopingtop]

首先要考虑你场景的一致性容忍度，如果一点就不能容忍，那么你就不应该用 redis 来做。应该选强一致性方案，也就是说的 etcd 或者 zk 。

redis 是做不了强一致性的，包括 多 client 端连接多 master (n/2)+1 这种方案，还有就是 redis wait 命令，都只能是减少锁失效的概率。

如果有容忍性，又是选举场景这种并发不大的情况，只需要找一块共享存储原子操作就行。member 去 loop 尝试加锁，leader 去续约就好。

如果 Leader 后续操作有数据库的话，这样 redis 这个依赖就能不要，减少一个自己不太熟悉的东西，提升稳定性。

不建议用 Pub 消息去通知。订阅可能存在失效等问题，而且这样实现就深度绑定了一些特性，以后不好做迁移。

[MoYi123]

没必要 pub, leader 加速时间设短点, 其他的设长点就好了.

[wencan]

@hopingtop
@MoYi123
pub/sub 算是增强，避免 slave 频繁尝试，也避免 leader 下线后没有立即开始新选举。