我对分布式和 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 加速时间设短点, 其他的设长点就好了.
|