xiyy02 最近的时间轴更新
xiyy02

xiyy02

V2EX 第 644153 号会员,加入于 2023-08-17 22:02:07 +08:00
今日活跃度排名 10823
根据 xiyy02 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
xiyy02 最近回复了
@Jasonhhh 之前看过这块内容,似乎 Redis 对于 Raft 的应用并不是直接作用到主从节点的,而是作用在 Sentinel 上的,而且基本上只是用 raft 的投票思想来做主节点客观下线和 Sentinel Leader 选举,被选举出的 Sentinel Leader 节点再去做故障转移(向同步数据 offset 最大的从节点发送 slaveof on one ,让其变成主节点,然后向其他从节点发送 slaveof 新主节点 ip+port 简历新的主从关系,从节点再发起 psync 同步,旧 master 若恢复就变成从节点,故障转移成功);
所以这个过程中 redis 主从节点间的数据同步其实也是简单的复制同步( psync+挤压缓冲区);

不过经过大家的回复我现在似乎已经理解了我所问的问题,感谢耐心回复~
@clocean 系统限制,得写月份,而且在年底这个节骨眼还不如直接写月份,写年反而吃亏😂
@V2April 应该不是,大部分消息都是已读状态,猎头大部分是把我的简历转给 hr 后筛选,这样感觉还不如直接找技术 leader 投或者找人内推来的快
@dlmy 我大概 gap 了 3 个多月(去年 11 月离职),这期间主要是驾考+过年,然后过年期间没面试,想着年后再面,我工作经历上肯定只能写到去年 11 月。。比较纠结怎么解释这段经历,我前天将简历改成「离职」状态,Boss 直聘和智联上面收到的私信有二三十条了,但都是我把简历发过去就没下文了,我担心 是不是这段 gap 期的缘故,或者是他们还没开始上班,没办法安排面试?
@JosephYin01 哈哈,那我主动联系,开始海投😂
@RICKEYGONG 好像也是哈😂
@happyxhw101 我理解 CAP 指的是在实现分布式一致性遇到网络分区( P )时的取舍方案( C or A ),而 Raft 协议是一种保证多副本共识而最终达到多副本强一致的策略,它们都是单独的理论,但在做工程实现时需要一起考虑:比如我有一个分布式系统通过 Raft 实现节点间的强一致,正常情况下,它确实是强一致的,而且运行的很好,但当发生网络分区时我需要结合 CAP 理论在可用性和一致性之间作取舍,如果要舍弃可用性,那就分区期间为了保证一致性让整个系统不可用(具体表现为客户端无法读或写),如果要舍弃强一致性,那就在分区期间也允许读写操作,但后果就是多节点间因为分区导致多 leader 写或单 leader 写的内容无法同步到没有 leader 的分区节点,导致各分区间的数据不一致。
额。。只是个人理解,不知道对不对,CAP 和 Raft 都是我最近在研究的东西,感觉都很抽象😭
@liprais 可是 raft 也保证不了完全的强一致吧?比如:leader 写了一个数据,此时同步到 Follower ,「多半」 Follower 响应 leader 后 leader 将此信息传给客户端,告知客户端已经写成功,但如果此时客户端读这个数据的时候正好读到了还未将此数据标记为 commited 状态的那个 Follower 节点(「多半」意味着总会有落后的 Follower ),这不就造成读写不一致了吗?
我看过 Quorum 规则,说客户端每次可以读半数以上的节点,以确保至少有一个节点可以读到最新的值,但这对于一个客户端来说操作似乎又太重了(一次请求那么多个节点显然不合适),就很晕😓
@momocraft 可是共识算法中不也是 leader 负责做决定,Follower 跟随吗?唯一的区别是 leader 身份可切换
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1055 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 19:11 · PVG 03:11 · LAX 11:11 · JFK 14:11
Developed with CodeLauncher
♥ Do have faith in what you're doing.