本文是观看Redis容灾体系构建-阿里云redis直播之后的个人总结，视频已附在文末。
架构
双副本
2个redis：master-slave
master有故障时，把slave提升为master。当旧master恢复后，它会被作为slave挂载到新master上。
读写请求都是访问的master。slave只是作为备用，不接受处理业务请求。
集群版
架构如下：
- proxy：proxy1，proxy2，proxy3…
- 双副本redis：
双副本redis1，双副本redis2，双副本redis3…
逻辑如下：
- proxy把读写请求进行分片，来决定落到哪个
双副本redis上。分片规则决定请求的读写必定落到 同一个双副本redis上。
集群版由于会把请求进行分片，每一个双副本redis要处理的请求就会减少了，会同时提高读和写的能力。
不过在业务中，常常是读多写少，提升写能力有点浪费。并且当读请求非常多的情况下（热点key），再加更多的集群的性价比可能较低，此时可以考虑读写分离。
读写分离
在业务中，常常是读多写少。当读请求非常多的情况下（热点key），可以考虑读写分离。
架构如下：
- proxy：proxy1，proxy2，proxy3…
- 只写redis：
双副本redis - 只读redis：
只读redis1，只读redis2，只读redis3…
逻辑如下：
- proxy来区分
读请求还是写请求，写请求落到只写redis上，读请求落到只读redis上，
只写redis的延迟问题：当redis都在同一机房部署时（单机房部署），两个只写redis的延迟大概是0.1ms，是可以接受的。
实际构建
没看懂，有些名词也不懂，看得想睡觉，就去睡觉了。。。
视频
本文会经常更新，请阅读原文： https://note.guoqianfan.com/2021/09/24/Redis%E5%AE%B9%E7%81%BE%E4%BD%93%E7%B3%BB%E6%9E%84%E5%BB%BA-%E9%98%BF%E9%87%8C%E4%BA%91/ ，以避免陈旧错误知识的误导，同时有更好的阅读体验。
如果你想持续阅读我的最新博客，请点击 RSS 订阅。
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布，但务必保留文章署名 过千帆的记事本（包含链接： https://note.guoqianfan.com ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请 与我联系 。