这是一个创建于 1004 天前的主题，其中的信息可能已经有所发展或是发生改变。
我对分布式和 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