后台Redis版本，无论是主从版本还是集群规格，副本都不作为备库对外提供服务。只有发生HA时，replica才会提升为master，承担读写流量。该架构的读写请求均在master上完成，一致性高，但性能受限于master数量。经常有用户数据量少，但是因为高流量或者高并发，不得不升级到更大的集群规模。为满足多读少写的业务场景，最大限度的为用户节约成本，云数据库Redis版推出读写分离规范，为用户提供透明、高可用、高性能、高弹性的读-写分离服务。架构Redis集群模式有redis-proxy、master、replica、HA等几个角色。在读写分离实例中，增加了一个只读副本角色来承担读流量。副本不作为热备提供服务，架构保持与现有集群规范的兼容性。redis-proxy根据权重将读写请求转发给master或者一个只读的replica；HA负责监控DB节点的健康状态，异常时发起主从切换或重置只读副本，更新路由。一般来说，根据master和只读副本的数据同步方式，可以分为星型复制和链式复制两种架构。星型复制星型复制是将所有只读副本直接同步到master。每个只读副本相互独立，任何节点异常不影响其他节点。同时，由于复制链比较短，只读唯一副本上的复制延迟比较小。Redis是单进程单线程模型，master和slave之间的数据复制也是在主线程中处理。只读副本越多，master上数据同步的CPU消耗越严重，集群的写性能会随着只读副本的增减而增加。此外，星型架构将允许master的出口带宽随着只读副本的增加呈指数增长。master上更高的CPU和网络负载将抵消星型复制的低延迟优势。因此，星型复制架构会造成严重的扩展问题，整个集群的性能会受到master的限制。链式复制链式复制将所有只读副本组织成一个复制链，如下图，master只需要同步数据到副本和复制链上的第一个只读副本。链式复制解决了星型复制的扩容问题。理论上，只读副本的数量可以无限增加。随着节点的增加，整个集群的性能基本可以线性增长。在链式复制架构下，复制链越长，复制链末端的只读副本与master之间的同步延迟就越大。考虑到读写分离主要用在对一致性要求不高的场景，这个缺点一般是可以接受的。但是，如果复制链中的某个节点出现异常，则所有下游节点的数据都会出现很大的滞后。更严重的是，这可能会带来全同步，而全同步会传递到复制链的末端，对服务造成一定的影响。为了解决这个问题，读写分离的Redis采用了阿里云优化的binlog副本版本，最大限度地降低了全同步的概率。结合上面的讨论和比较，Redis读写分离选择了链式复制的架构。Redis读写分离的优点是透明、兼容，读写分离与普通集群规范相同。Redis-proxy用于请求转发。多分片的使用有一定的限制，但是从主从升级到单分片读写分离，或者从集群的读写分离集群升级到多分片都可以完全兼容。当用户与redis-proxy建立连接时，redis-proxy会识别client连接发送的请求是读还是写，然后根据权重进行负载均衡，将请求转发到后端不同的DB节点，并将写请求转发给master，读操作转发给只读副本（master默认也提供read，可以通过权重控制）。用户只需购买一个读写分离规格的实例，即可直接使用任意客户端。业务无需任何修改即可开始享受读写分离服务带来的巨大性能提升，接入成本几乎为零。高可用性高可用性模块（HA）监控所有DB节点的健康状态，以确保整个实例的可用性。当master宕机时，它会自动切换到新的master。如果只读副本宕机，HA也能及时检测到，然后重建新的只读副本，使宕机节点下线。除了HA之外，redis-proxy还可以实时感知各个只读副本的状态。只读副本异常时，redis-proxy会自动降低本节点的权重。如果一个只读副本连续失败超过一定次数，它会暂时阻塞异常节点，直到异常消失才会恢复。正常体重。Redis-proxy和HA协同工作，最大限度地减少业务对后端异常的感知，提高服务可用性。高性能对于读多写少的业务场景，直接使用集群版本往往不是最合适的方案。现在读写分离提供了更多的选择。业务可以根据场景选择最合适的规格，充分利用各个只读Replica资源。目前单个分片以1master+1/3/5只读副本多种规格出售（如有更大需求，可提交工单反馈），提供60万QPS、192MB/s服务能力，完全兼容所有命令的情况下，突破了单机的资源限制。未来将取消规格限制，允许用户根据业务流量随时自由增减只读副本数量。后续Redis主从异步复制可能会从只读副本读取旧数据。使用读写分离需要业务容忍一定程度的数据不一致。未来会给予客户更灵活的配置和更大的自由度，比如配置可以容忍的最大延迟。
