面试官：你的 Redis 怎样做读写别离的？

时间：2021-08-05 21:10 来源：网络整理作者：网络浏览：次收藏挑错推荐打印

前几天，一个读者去面试，面试官就问了他关于Redis读写别离是怎样做的？本来脑子里也有不少知识要讲，不过猛的被面试官一问给当场干懵逼了........。

这不，昨天早晨他在微信上问我，所以，明天给大家分享一下这方面的知识点。

背景

Redis 不管主从版还是集群规格，replica作为备库不对外提供效劳，只要在发作HA的时分，replica提升为master后才承当读写流量。这种架构读写央求都在master上完成，分歧性较高，但功用遭到master数量的限制。常常有用户数据较少，但由于流量或许并发太高而不得不晋级到更大的集群规格。

为满足读多写少的业务场景，最大化浪费用户成本，云数据库Redis版推出了读写别离规格，为用户提供透明、高可用、高功用、高灵敏的读写别离效劳

架构

Redis集群形式有redis-proxy、master、replica、HA等几个角色。在读写别离实例中，新增read-only replica角色来承当读流量，replica作为热备不提供效劳，架构上保持对现有集群规格的兼容性。redis-proxy按权重将读写央求转发到master或许某个read-only replica上；HA担任监控DB节点的安康形状，异常时发起主从切换或重搭read-only replica，并更新路由。

普通来说，依据master和read-only replica的数据同步方式，可以分为两种架构：星型复制和链式复制。

星型复制

星型复制就是将一切的read-only replica直接和master保持同步，每个read-only replica之间相互独立，任何一个节点异常不影响到其他节点，同时由于复制链比较短，read-only replica上的复制延迟比较小。

面试官：你的 Redis 怎样做读写别离的？

Redis是单进程单线程模型，主从之间的数据复制也在主线程中处置，read-only replica数量越多，数据同步对master的CPU消耗就越严重，集群的写入功用会随着read-only replica的添加而降低。此外，星型架构会让master的出口带宽随着read-only replica的添加而成倍增长。Master上较高的CPU和网络负载会抵消掉星型复制延迟较低的优势，因此，星型复制架构会带来比较严重的扩展成绩，整个集群的功用会受限于master。

链式复制

链式复制将一切的read-only replica组织成一个复制链，如下图所示，master只需求将数据同步给replica和复制链上的第一个read-only replica。

链式复制处置了星型复制的扩展成绩，实际上可以有限添加read-only replica的数量，随着节点的添加整个集群的功用也可以基本上呈线性增长。

面试官：你的 Redis 怎样做读写别离的？

链式复制的架构下，复制链越长，复制链末端的read-only replica和master之间的同步延迟就越大，思索到读写别离主要运用在对分歧性要求不高的场景下，这个缺陷普通可以接受。但是假设复制链中的某个节点异常，会招致下游的一切节点数据都会大幅滞后。愈加严重的是这能够带来全量同步，并且全量同步将不断传递到复制链的末端，这会对效劳带来一定的影响。为了处置这个成绩，读写别离的Redis都运用阿里云优化后的binlog复制版本，最大水平的降低全量同步的概率。

更多关于Redis技术栈的学习，可以关注民工哥技术之路群众号，在Redis专栏中查看相关的技术文章、面试题及答案，十分详细，继续更新中。

Redis读写别离优势透明兼容

读写别离和普通集群规格一样，都运用了redis-proxy做央求转发，多分片令运用存在一定的限制，但从主从晋级单分片读写别离，或许从集群晋级到多分片的读写别离集群可以做到完全兼容。

用户和redis-proxy树立衔接，redis-proxy会辨认出客户端衔接发送过去的央求是读还是写，然后按照权重作负载平衡，将央求转发到后端不同的DB节点中，写央求转发给master，读操作转发给read-only replica（master默许也提供读，可以经过权重控制）。

用户只需求购置读写别离规格的实例，直接运用任何客户端即可直接运用，业务不用做任何修正就可以末尾享用读写别离效劳带来的庞大功用提升，接入成本简直为0。

高可用

高可用模块（HA）监控一切DB节点的安康形状，为整个实例的可用性保驾护航。master宕机时自动切换到新主。假设某个read-only replica宕机，HA也能及时感知，然后重搭一个新的read-only replica，下线宕机节点。

除HA之外，redis-proxy也能实时感知每个read-only replica的形状。在某个read-only replica异常时期，redis-proxy会自动降低这个节点的权重，假设发现某个read-only replica延续失败超过一定次数以后，会暂时屏蔽异常节点，直到异常消逝以后才会恢复其正常权重。

redis-proxy和HA一同做到尽量增加业务对后端异常的感知，提高效劳可用性。

高功用

关于读多写少的业务场景，直接运用集群版本往往不是最适宜的方案，如今读写别离提供了更多的选择，业务可以依据场景选择最适宜的规格，充沛应用每一个read-only replica的资源。

目前单shard对外售卖1 master + 1/3/5 read-only replica多种规格（假设有更大的需求可以提工单反应），提供60万QPS和192 MB/s的效劳才能，在完全兼容一切命令的状况下打破单机的资源限制。后续将去掉规格限制，让用户依据业务流量随时自在的添加或增加read-only replica数量。

面试官：你的 Redis 怎样做读写别离的？