首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >「腾讯云 NoSQL」技术之 Redis 篇:针对集群选举投票冲突的优化方案

「腾讯云 NoSQL」技术之 Redis 篇:针对集群选举投票冲突的优化方案

作者头像
腾讯云NoSQL技术
发布2026-06-26 15:14:17
发布2026-06-26 15:14:17
3002
举报
概述
通过引入 shard_id 字典序的故障分片排名,使多个故障分片按确定顺序错峰发起选举,从而降低选票冲突概率,提升集群自愈成功率。
文章被收录于专栏:NoSQL技术干货NoSQL技术干货

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • auth_timeout:单次选举的超时时间
  • 把两个计时器叠起来看
  • data_age 的计算
  • 关键洞察:所谓"3 次重试"其实是 data_age 自然耗尽的副产物
  • epoch 是什么
  • 为什么"一 epoch 一票"不能动
  • 重试为什么也救不回来?
  • 小概率事件,乘以巨大基数
  • 规模放大:当大量主节点一起故障
  • 这次优化为什么这么重要
  • 核心思路:用延迟代替锁,用确定性代替概率
  • 排序键:为什么是 shard_id
  • 两层 rank,各司其职
    • 关键就在那确定的 500ms 间隔:随机延迟会让两个时刻各自浮动,但 failed_primary_rank 带来的这 500ms 是确定性偏移,足以让两个 shard 大概率不再撞在同一瞬间——shard1 先进场抢票,shard2 退后半秒,等它进场时第一轮往往已经分出胜负。
  • 改造前:踩踏现场(5 分片 / 2 主挂)
  • 改造后:错峰发车(5 分片 / 2 主挂)
  • 串行化的隐性收益:先恢复的,反过来增援后恢复的
  • 不只是兜底:日常可用性的全面提升
  • 实际收益
  • 副本怎么知道自己输了?
  • 一图看清差别
  • 三管齐下:两层预防 + 一层兜底
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档