过千帆的记事本 记录点滴

Redis读写分离介绍-阿里云

2021-09-22
过千帆

本文是观看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

星型

redis-读写分离-星型

所有的slave都直接连接到master上。

优点:

  • ro-slave之间相互独立
  • 复制链短,同步延迟小
  • 故障恢复简单。

    master有故障时,选一个有最新数据的slave提升为master即可,其他slave都连接到这个新的master上。

    slave挂掉时,直接去除掉它,再添加一个新的slave即可。

缺点:

  • master同步压力大
  • CPU&带宽放大效应,限制扩展能力

有几个slave,master就需要把数据复制几份,同步到slave上。

同步任务是由redis主线程做的,但是redis主线程还需要处理业务的正常命令,同步任务穿插进来会干扰正常命令的执行的。

CPU&带宽亦是如此。有几个slave,master就需要把数据复制几份,同步到slave上。CPU&带宽都会倍增,当达到服务器的限制后,就不能再增加slave了。

链式

redis-读写分离-链式

优点:

  • 无限扩展。

    因为是链式的,想扩展了,在尾部追加一个新的即可。

  • 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 ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系


Similar Posts

Comments