共计 2357 个字符，预计需要花费 6 分钟才能阅读完成。
背景
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 是单过程单线程模型，主从之间的数据复制也在主线程中解决，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 的数量，随着节点的减少整个集群的性能也能够基本上呈线性增长。
链式复制的架构下，复制链越长，复制链末端的 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 一起做到尽量减少业务对后端异样的感知，进步服务可用性。能够参考：Redis 低成本高可用计划
高性能
对于读多写少的业务场景，间接应用集群版本往往不是最合适的计划，当初读写拆散提供了更多的抉择，业务能够依据场景抉择最适宜的规格，充分利用每一个 read-only replica 的资源。
目前单 shard 对外售卖 1 master + 1/3/5 read-only replica 多种规格（如果有更大的需要能够提工单反馈），提供 60 万 QPS 和 192 MB/ s 的服务能力，在齐全兼容所有命令的状况下冲破单机的资源限度。后续将去掉规格限度，让用户依据业务流量随时自在的减少或缩小 read-only replica 数量。
Redis 主从异步复制，从 read-only replica 中可能读到旧的数据，应用读写拆散须要业务能够容忍肯定水平的数据不统一，后续将会给客户更灵便的配置和更大的自在，例如配置能够容忍的最大延迟时间。
作者：小酷爱
起源：juejin.cn/post/6955355686108659726