摘要：在2018数据库直播大讲堂峰会-Redis专场上，阿里云的Redis开发者午光对Redis读写分离进行了介绍。对Redis读写分离可以解决哪些问题，可以应用在哪些场景中，满足业务的哪种需求分别进行了讲解。
直播视频：https://yq.aliyun.com/video/play/1312
PDF下载：https://yq.aliyun.com/download/2448
以下为精彩视频整理：
Redis读写分离——解决的问题
对于Redis读写分离主要解决了哪些问题，我们今天主要从接下来的四个方面来进行解读。
第一个是业务流量的读多写少，对这种读多写少或读容量比较大的，读容量从主库倒到从库上去，这个时候主库压力就可以小一点，承担更大的写的压力。读容量越多，读写比越大，加更多的节点。
第二个是慢查多，对Redis来说是有一些比较耗时的命令，用读写分离的话，就可以把慢查的读的流量放到从库里，然后在从库里随便做。主库可以继续承担写的压力。这时候就可以非常轻松的慢查了。
第三个是Big key问题，Redis丰富的数据结构用起来非常的方便也非常灵活。我们做数据库开发经常接触的客户有非常多的案例，用的太爽太方便以后就会带来Big key问题。读写分离可以解决某种场景下的Big key问题。
第四个就是热点读的问题，当把数据再一步往上移，客户端把数据返回到业务端，就可以热点读。这只是一方面，但是这种实现的时候就会比较复杂，实验起来会比较麻烦。在读写分离上怎么解决热点读的，我们加上仓库，分散的去读就可以了。
阿里云Redis读写分离——架构
对阿里云Redis读写分离底层的一些架构，很多用户用过读写分离后感觉非常方便，阿里云Redis读写分离和架构相关的东西就是Redis的master节点和主读从库节点之间的复制关系该怎么复制，上图是一个星型的复制，主库需要挂几个从库然后提供读服务。它有一下几点优点：
（1）主读从库各个从库之间，它们各自之间都是相互独立的，各个主读从库之间是没有关系的。
（2）它的复制链很短各个主读从库和主库是直接相连的只需要复制一节，这个延迟取决于网络时延和主库从库的CPU压力有关。所以说它是复制链比较短，同步延迟也比较小的。
（3）故障恢复相对来说也简单一点，如果主读从库挂了是没有关系的，直接摘掉就好了。如果说主库挂了，只要选一个最新数据的主读从库去提升为主库，在和它进行连接就好了。
它的缺点有如下两点：
（1）master同步压力大。
（2）CPU&带宽放大效应限制扩展能力。
链式复制就是一个主库挂一个主读从库，主读从库下面在挂一个主读从库一直挂过去。它的优点是可以无限的扩展，master的同步压力也比较小。
它的缺点有如下两点：
（1）复制链越长同步延迟越大，从主从到复制链末端的一个主读从库的同步延迟我们是有监控的，可以观测是什么导致的故障。
（2）另一个缺点就是恢复比较麻烦，比如说复制链中间的某个只读节点挂了，那我们就要它下面的一个好的节点接到它上游，让复制链保持畅通。
综合上面的考虑，最终我们选用的是链式复制的架构，框架图如下：
现在在我们网站上购买一个读写分离的实例，这个读写分离实例上面用的通过给的地址访问的所有的架构就是这样的。购买一个实例后肯定是有一个域名的，上面有一层负载均衡，负载均衡下面是接着proxy，proxy是做流量转发的，机群上面是有一层代理做流量转发，对读写分离也是有一层代理的，这个代理最主要的功能就是消息转发，消息转发把写的流量都转移到master上。
HA模块是做高可用，就是一个主读从库挂了该怎么处理，这是高可用模块主要负责的事情，要监控各节点健康状态。发起主从切换，主从切换就是master挂了，要把slave切换成master，复制链也重新建好。然后是发起ro-slave重搭，如果说业务中第二个主读从库挂了，这个图里是一个主库带了三个节点，这个时候proxy就会自动的把流量转发到其他的节点上去，其他节点的压力就会上升，这时就要把故障节点摘掉，摘掉后立马新建一个主读从库，新建的主读从库复制链的末端第三个节点去同步数据。
Proxy模块对读写分离有非常重要的作用，要去感知Redis的状态，比如说某一个主读从库挂了，如果一直等待HA感知节点，因为感知是需要时间的，这个时间的业务流量就会全部失败，所以Proxy是要感知Redis的状态的。Proxy可以动态调整权重，主读从库做Proxy流量转发是有一个加权，权重就决定了每个主读从库抗多少的比例的流量。大多数情况下主读从库都是默认的权重都是一样的，当Proxy感受到异常就会进行调整。还有一种情况是节点彻底的挂了，Proxy也是直接就会感知到，这个时候是可以暂时的屏蔽一段时间，过一段时间后放一个流量过去，感知一下是不是好的，是好的在逐渐把权重恢复起来，如果还是不行就继续屏蔽一段时间。
Proxy有如下四个的优点：
（1）只有一个访问地址，都是通过一个地址来访问
（2）100％命令兼容
（3）负载均衡
（4）高可用，是根据业务的流量去感知各个节点的状态，智能的去调整它。
阿里云Redis读写分离——一致性
讲了很多读写分离的缺点现在来说说它的缺点，读写分离的缺点就是一致性，要有读写分离就要容忍业务是不一致的，也就是一致性没有那么高，不要求有强一致性。
左边这个图相对来说会比较简单一点，假设去主库里面写了一条数据正常返回了，比如先前写的数据是value1，过了一会再写一条把数据改了，改后立马去读，这时读流量重复上面去执行，这时返回的数据是旧的，这个结果是否可以接受，能接受就完全没问题。
右边这个图稍微复杂一点，优点类似于不可重复读。假设写一条数据value1，写完之后到各个从库里面最后value就是value1。接下来客户端又写了一条新数据，立马就进行读，这个时候假设有连续三个读流量，第一个获得最新的。第二个读请求读的是旧的是value1,。第三个读请求获得了最新的数据。
阿里云Redis读写分离——售卖与使用
阿里的Redis读写分离的规格应该是在2017年的下半年开始正式上线的。目前我们的读写分离接入是0成本，命令也是100%兼容的，主从到读写分离是自动升级的，可以提供60Wqps和192MB/s的服务能力，目前提供1master + 1/3/5 readonly slave。
读写分离现在可以购买的一些规格中最小的是1GB的读写分离版本，带一个只读节点。最高的是32GB读写分离版本，带有五个只读节点，这个已经可以满足大部分客户的需求了。以后我们会推出更丰富的读写分离版本，我们的目标是让用户用的更加方便更加灵活。
本文由云栖志愿小组陈欢整理，百见编辑。