Redis集群架构视频课程（核心作用+集群实现方案）视频教程 百度云下载

这套 Redis 集群架构课程围绕一个很具体的问题展开：单机 Redis 撑不住的时候，怎么把数据分散到多节点、怎么在节点故障时自动切换、怎么让客户端正确寻址。它覆盖三条技术路线——Sentinel、Twemproxy、Redis Cluster，这三者不是并列的替代品，而是代表了 Redis 高可用与分片方案在不同阶段、不同约束下的取舍。资料本身是视频形式，配套了章节笔记，适合拿来对照自己的部署环境边看边改配置。

三条路线各自解决什么

Sentinel 解决的是主从架构下的故障检测与自动故障转移。它的核心不是分片，而是监控、通知、选主、通知客户端这一套流程。学习者需要关注的重点在哨兵之间的通信与共识、主观下线与客观下线的判定差异、failover 之后客户端如何拿到新主节点地址。这些逻辑不跑一遍完整的主从加哨兵拓扑，只看配置项是理解不透的。

Twemproxy 解决的是客户端侧分片，它作为代理层把请求按一致性哈希分发到后端多个 Redis 实例。它的价值在于对业务代码透明，客户端连一个代理地址即可。但代理本身的无状态特性和单点风险、以及不支持部分命令（如跨 key 操作）的限制，是工程上必须提前确认的边界。课程里对分片算法和后端节点扩缩容的处理，是这块最值得反复看的部分。

Redis Cluster 是官方原生的分片加高可用方案，用 16384 个哈希槽把数据切分到多个主节点，每个主节点带从节点做副本。它把分片、故障转移、客户端重定向（MOVED/ASK）都收敛到协议层，代价是运维复杂度和对多 key 命令的限制。槽位分配、集群重新分片、节点握手与 gossip 协议这几块，是理解 Cluster 的关键节点。

适合拿来对照实践的内容

这类中间件课程的价值不在概念讲得多全，而在配置和排障过程是否可复现。建议在跟学的同时，自己搭一套最小拓扑：三个主节点加三个从节点跑 Cluster，另一套一主两从加三哨兵跑 Sentinel，Twemproxy 至少起两个代理实例对比分片结果。把节点宕掉、手动触发 failover、模拟槽位迁移这些操作做一遍，观察客户端行为和日志输出。

章节笔记适合用来做配置对照表。把每个方案的启动参数、客户端连接方式、故障转移触发条件、扩缩容步骤整理成一张表，比反复看视频更能形成长期可查的工程参考。尤其是 Sentinel 和 Cluster 在故障转移触发条件上的差异，以及 Twemproxy 与 Cluster 在客户端接入方式上的区别，整理清楚后基本就能判断一个线上场景该选哪条路。

阅读与学习顺序建议

• 先看 Sentinel，理解主从复制与故障转移的基本机制，这是后面两个方案的基础。
• 再看 Twemproxy，重点放在分片算法与代理层带来的透明性和限制上。
• 最后看 Redis Cluster，槽位、重定向、gossip 通信是核心，配合自己搭集群验证。
• 每看完一个方案，把配置项、客户端行为、故障处理做成笔记，而不是只看不记。

课程偏向运维和架构侧，涉及较多部署与调优参数，适合已经能独立部署单机 Redis、想进一步理解分布式部署的开发者。对纯业务开发来说，理解客户端的重定向和分片逻辑同样有用，能避免踩到跨 key 操作、批量命令这类限制的坑。