这是一个创建于 700 天前的主题，其中的信息可能已经有所发展或是发生改变。
我对分布式和 redis 了解有限，所以还清大家帮忙看看。
服务启动时，每个实例尝试对 key 加锁，加锁成功的成为 leader 。加锁办法为 lua 脚本。有更好的加锁办法，请推荐。 leader 实例退出时，解锁，pub 消息通知其它实例，其它实例开始尝试加锁。 锁有超时时间，每次超时时间过半，leader 给 key 续时。如果 leader 非正常原因挂掉，key 会超时。 其它实例间隔随机时间尝试加锁， 或者收到 leader 退出消息时也尝试加锁，加锁成功的成为 leader 。
 |
1
leonme 2023-01-12 09:03:33 +08:00 via iPhone
相比于 raft 协议的优势在哪儿？
|
 |
2
detached 2023-01-12 09:15:30 +08:00
楼上灵魂拷问了，你的 motivation 在哪里，你的 novelty 在哪里 hhhh
|
 |
3
Cola98 2023-01-12 09:50:42 +08:00
多个实例都尝试做加锁的时候怎么解决？
|
 |
4
morty0 2023-01-12 09:57:24 +08:00
网络分区的情况怎么考虑
|
 |
5
sujin190 2023-01-12 10:33:08 +08:00 via Android
@morty0 redis 只能单主的，不存在网络分区问题吧，网络分区后 redis 在哪个区只有哪个区能用，都不在就都不能用
|
 |
6
ql562482472 2023-01-12 10:45:09 +08:00
@detached 现在越来越觉得这非常重要，做事有逻辑，有出发点，有落地点 怪不得以前进不去大厂 小厂自嗨的看多了 还真的能理解这些了
|
 |
7
rrfeng 2023-01-12 10:48:59 +08:00
不错，现实中如果已经依赖了 Redis 这是个很简单有效的解决方案。相同方案也可以使用 MySQL ，或者其他任何支持 cap/事务的共享存储上。
说 raft 的，为了这么个破功能部署一套 etcd ？呵呵。 |
 |
9
hopingtop 2023-01-12 13:50:33 +08:00
首先要考虑你场景的一致性容忍度，如果一点就不能容忍，那么你就不应该用 redis 来做。应该选强一致性方案，也就是说的 etcd 或者 zk 。
redis 是做不了强一致性的，包括 多 client 端连接多 master (n/2)+1 这种方案，还有就是 redis wait 命令，都只能是减少锁失效的概率。 如果有容忍性，又是选举场景这种并发不大的情况，只需要找一块共享存储原子操作就行。member 去 loop 尝试加锁，leader 去续约就好。 如果 Leader 后续操作有数据库的话，这样 redis 这个依赖就能不要，减少一个自己不太熟悉的东西，提升稳定性。 不建议用 Pub 消息去通知。订阅可能存在失效等问题，而且这样实现就深度绑定了一些特性，以后不好做迁移。 |
 |
10
MoYi123 2023-01-12 15:43:19 +08:00
没必要 pub, leader 加速时间设短点, 其他的设长点就好了.
|
Select Language