本文是观看Redis读写分离介绍-阿里云redis直播之后的个人总结，视频已附在文末。
适用场景
redis读写分离适用场景：
- 业务流量读多写少
- 慢查多
- Big key
- 热数据
业务流量读多写少
读与写之间是矛盾的。
- 写：独占锁，其他任何操作都不能进行
- 读：共享锁，可以再次附加读操作，除此之外禁止其他任何操作。
因此，读多、写多时，势必会相互影响的。在外界看来就是很慢。
可以让master承担写操作，slave承担读操作，读写分离，这样读和写的效率都会提高很多。
慢查多
redis是单进程的，所有命令都由一个进程来处理。当某个命令耗时过长时，后面的命令都得等待。外界看来就是耗时很长。
此时可以把慢查命令放到单独的slave里，master和其他 的slave仍然正常工作，快速响应。
Big key
Big key不是指key的长度非常长，而是指k-v这一个整体非常大。例如list、zset的元素非常多。
对于Big key，当是O(N)操作时，耗时会非常长，算是个小慢查的操作。例如获取所有元素，就需要遍历一遍。
热数据
热点读，master扛不住，就分散到slave上去读。
热点，说明命令非常多，积累起来的总耗时也就很大了。
实现方式
实现方式有3种：
- 星型：1 master->全部的直接slave
- 链式：1 master->1个直接slave->1个直接slave->…
- 二叉树：1 master->少量的直接slave->少量的直接slave
星型
所有的slave都直接连接到master上。
优点：
- ro-slave之间相互独立
- 复制链短，同步延迟小
-
故障恢复简单。
master有故障时，选一个有最新数据的slave提升为master即可，其他slave都连接到这个新的master上。
slave挂掉时，直接去除掉它，再添加一个新的slave即可。
缺点：
- master同步压力大
- CPU&带宽放大效应，限制扩展能力
有几个slave，master就需要把数据复制几份，同步到slave上。
同步任务是由redis主线程做的，但是redis主线程还需要处理业务的正常命令，同步任务穿插进来会干扰正常命令的执行的。
CPU&带宽亦是如此。有几个slave，master就需要把数据复制几份，同步到slave上。CPU&带宽都会倍增，当达到服务器的限制后，就不能再增加slave了。
链式
优点：
-
无限扩展。
因为是链式的，想扩展了，在尾部追加一个新的即可。
-
master同步压力小
master只负责与它直连的一个slave即可。每个slave也都只负责与它直连的一个slave即可。
缺点：
-
复制链越长，同步延迟越大
每一节的复制都是需要时间的，越到后面，所需时间越长。
-
故障恢复麻烦
当故障发生在中间的
m节点时，就需要把m后面的连到m前面的上面，然后？？？好像是需要全量同步的，后面的所有节点也都需要全量同步，耗时较长。
二叉树
结合 星星 和 链式。
把优点结合了一下，缺点也都沾点。故障恢复不知道咋搞，但总感觉很麻烦，也想不出来。。。
视频
本文会经常更新，请阅读原文： https://note.guoqianfan.com/2021/09/22/Redis%E8%AF%BB%E5%86%99%E5%88%86%E7%A6%BB%E4%BB%8B%E7%BB%8D-%E9%98%BF%E9%87%8C%E4%BA%91/ ，以避免陈旧错误知识的误导，同时有更好的阅读体验。
如果你想持续阅读我的最新博客，请点击 RSS 订阅。
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布，但务必保留文章署名 过千帆的记事本（包含链接： https://note.guoqianfan.com ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请 与我联系 。