阿里云Redis读写分离典型场景：如何轻松搭建电商秒杀系统
https://yq.aliyun.com/articles/277885
文末有彩蛋，请务必记得看完整哦
背景
目前的阿里云redis不管主从版还是集群规格，slave作为备库不对外提供服务，只有在发生HA，slave提升为master后才承担读写。这种架构读写请求都在master上完成，一致性较高，但性能受到master数量的限制。经常有用户数据较少，但因为流量或者并发太高而不得不升级到更大的集群规格。
为满足读多写少的业务场景，最大化节约用户成本，阿里云redis推出了读写分离规格，为用户提供透明、高可用、高性能、高灵活的读写分离服务。
架构
目前的redis集群模式有redis-proxy, master,slave, HA等几个角色，在读写分离中，新增readonly slave角色承担读流量，slave作为热备不提供服务，架构上保持对现有集群规格的兼容性。redis-proxy按权重将读写请求转发到master或者某个readonly slave上；HA负责监控DB节点的健康状态，异常时发起主从切换或重搭readonly slave，并更新路由。
一般来说，根据master和readonly slave的数据同步方式，可以有两种架构：星型复制，链式复制。
星型复制
星型复制就是将所有的readonly slave直接和master保持同步，每个readonly slave之间相互独立，任何一个节点异常不影响到其他节点，同时因为复制链比较短，readonly slave上的复制延迟比较小。
redis是单进程单线程模型，主从之间的数据复制也在主线程中处理，readonly slave数量越多，数据同步对master的cpu消耗就越严重，集群的写入性能会随着readonly slave的增加而降低。此外，星型架构会让master的出口带宽随着readonly slave的增加而成倍增长。master上较高的CPU和网络负载又会抵消掉星型复制延迟较低的优势。可以看出，星型复制架构会带来比较严重的扩展问题，整个集群的性能会受限于master。
链式复制
链式复制将所有的readonly slave组织成一个复制链，如下图所示，master只需要将数据同步给slave和复制链上的第一个readonly slave。
链式复制解决了星型复制的扩展问题，理论上可以无限增加readonly slave的数量，随着节点的增加整个集群的性能也可以基本上呈线性增长。
链式复制的架构下，复制链越长，复制链末端的readonly slave和master之间的同步延迟就越大，考虑到读写分离主要使用在对一致性要求不高的场景下，这个缺点一般可以接受。但是如果复制链中的某个节点异常，会导致下游的所有节点数据都会大幅滞后，更加严重的是这可能带来全量同步，并且全量同步将一直传递到复制链的末端，这会对服务带来一定的影响，为了解决这个问题，读写分离的redis都使用阿里云优化后的binlog复制版本，最大程度的降低全量同步的概率。
结合上述的讨论和比较，redis的读写分离选择链式复制的架构。
透明、兼容
读写分离和普通集群规格一样，都使用了redis-proxy做请求转发，多shard时部分命令使用存在一定的限制，但从主从升级单分片读写分离，或者从集群升级到多分片的读写分离集群可以做到完全兼容。
| 规格 | 主从版本 | 读写分离（单shard） | 集群 | 读写分离集群 |
|---|---|---|---|---|
| 兼容性 | 100% | 100% | 部分命令使用受到限制 | 部分命令使用受到限制 |
在集群模式下，有部分命令使用必须限制所有key在同一个slot中，具体可以参考阿里云官网：https://help.aliyun.com/document_detail/26356.html?spm=5176.doc43829.6.562.NDJFXm
用户和redis-proxy建立连接，redis-proxy会识别出客户端连接发送过来的请求是读还是写，然后按照权重作负载均衡，将请求转发到后端不同的DB节点中，写请求转发给master，读操作转发给readonly slave（master默认也提供读，可以通过权重控制）。
用户只需要购买读写分离规格的实例，直接使用任何客户端即可直接使用，业务不用做任何修改就可以开始享受读写分离服务带来的巨大性能提升，接入成本几乎为0。
高可用
高可用模块（HA）监控所有DB节点的健康状态，为整个实例的可用性保驾护航，master宕机时自动切换到新主。如果某个readonly slave宕机，HA也能及时感知，然后重搭一个新的readonly slave，下线宕机节点。
除HA之外，redis-proxy也能实时感知每个readonly slave的状态。在某个readonly slave异常期间，redis-proxy会自动降低这个节点的权重，如果发现某个readonly slave连续失败超过一定次数以后，会暂时屏蔽异常节点，直到异常消失以后才会恢复其正常权重。
redis-proxy和HA一起做到尽量减少业务对后端异常的感知，提高服务可用性。
性能
对于读多写少的业务场景，直接使用集群版本往往不是最合适的方案，现在读写分离提供了更多的选择，业务可以根据场景选择最适合的规格，充分利用每一个readonly slave的资源。
目前单shard对外售卖1master + 1/3/5 readonly slave多种规格（如果有更大的需求可以提工单反馈给我们），提供60W qps 和 192MByte/s的服务能力，在完全兼容所有命令的情况下突破单机的资源限制。后续将去掉规格限制，让用户根据业务流量随时自由的增加或减少readonly slave数量。
| 规格 | qps | 带宽 |
|---|---|---|
| 1 master | 8~10W读写 | 10~48MB |
| 1 master + 1 readonly_slave | 10W写 + 10W读 | 20~64MB |
| 1 master + 3 readonly_slave | 10W写 + 30W读 | 40~128MB |
| 1 master + 5 readonly_slave | 10W写 + 50W读 | 60~192MB |
其他
redis主从异步复制，从readonly slave中可能读到旧的数据，使用读写分离需要业务可以容忍一定程度的数据不一致，后续将会给客户更灵活的配置和更大的自由，比如配置可以容忍的最大延迟时间。
更多的购买和使用细节可以移步官网：https://promotion.aliyun.com/ntms/act/redisseparation.html
这里是彩蛋
感谢各位小伙伴的耐心阅读，现在参加Redis读写分离微博转发活动还有机会获得2017年 FIFA世俱杯门票以及阿里云T恤
点击云栖社区官方微博活动链接：https://weibo.com/1939498534/FydFv4EB1?ref=home&type=comment#_rnd1512444442357 ，12月6日抽取8名幸运用户2017年 FIFA世俱杯门票1张，12月12日抽20名幸运用户赠阿里云T恤1件。
