00-总结
2026/9/27大约 2 分钟
集群数量为什么设置单数
最低票数 = (N/2 )+ 1 (即 N 除以 2 的整数部分,再加 1)
- 3个节点:过半是2。允许宕机
3 - 2 = 1台。 - 4个节点:过半是3。允许宕机
4 - 3 = 1台。
问题:按照公式3个节点,假设挂了一个主节点,生效2个从节点都投票给自己怎么办?
- 选举超时时间是“随机”的。假设极端情况下,两台机器的时钟完全同步,且随机数生成器恰好产生了相同的值(概率极低),它们可能会同时触发选举。
- 这正是 Raft 论文中提到的 “活锁(Livelock)” 风险。但算法在选举失败后(比如双方各得1票,无人过半),会让它们重新生成一个新的随机超时时间,然后重新竞争。经过最多 2~3 轮,必然有一方先抢到。
RDB持久化触发时机
- 手动触发
- 使用save命令
- 使用bgsave命令
- 自动触发:
- 配置了
save m n - 主从同步:
flushall 或者 flush db清空数据或者清空db
- 配置了
秒杀如何设计
- lua脚本设计
- 防止用户重复下单
- 库存判断 > 0
- 库存-1
- 存储抢单成功的用户
- 异步创建订单发送MQ消息:
- MQ消息操作数据库的扣减,和单据的创建。
- 如果创建订单失败要考虑重试机制,还是恢复库存。
redis6.0之前为什么不使用多线程
慢查询和pipeline批处理
渐进式rehase、缓存时间戳
redis使用场景
| 数据类型 | 底层结构 | 场景 | 格式 |
|---|---|---|---|
| String | SDS | 缓存、分布式锁、分布式id | key:value |
| List | 双向列表,压缩列表 | 购物车、分布式锁 | key:value1,value1,value2....... |
| Hash | 压缩列表,Hash表 | 列表结构、队列结构、栈结构 | key:field1:value1,field2:value2.......... |
| Set | 整数集合,Hash表 | 抽奖、点赞、求交集。 | key:value1,value2,value3....... |
| SortedSet | 压缩列表,跳表 | 排行榜 | key:score1-value1,score2-value2............. |
redis如何实现上亿用户的实时排行榜
- zset 做排名,key=业务描述,score=userid,value=排名
- 数据量比较大的情况下,可以把大key拆分成小key,key=业务描述:0-1000,score=userid,value=排名。
用户连续登录的天数
BitMaps表示当天的签到情况。
- 如果用户id作为key,bit位代表当天数标记是否签到
- 如果时间作为key,bit位代表用户当天是否签到,建议以时间作为签到
setbit <key> <offset> <value>