阿里云Redis数据库技术解析.pdfVIP

阿里云 Redis 数据库技术解析 1 背景 目前的阿里云 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 上的复制延迟比 较小。 2 redis 是单进程单线程模型，主从之间的数据复制也在主线程中处理， readonly slave 数量越多，数 据同步对 master 的 cpu 消耗就越严重，集群的写入性能会随着 readonly slave 的增加而降低。此 外，星型架构会让 master 的出口带宽随着 readonly slave 的增加而成倍增长。 master 上较高的 CPU 和网络负载又会抵消掉星型复制延迟较低的优势。可以看出，星型复制架构会带来比较严重的扩展问 题，整个集群的性能会受限于 master 。 链式复制 3 链式复制将所有的 readonly slave 组织成一个复制链，如下图所示， master 只需要将数据同步给 slave 和复制链上的第一个 readonly slave 。 链式复制解决了星型复制的扩展问题，理论上可以无限增加 readonly slave 的数量，随着节点的增 加整个集群的性能也可以基本上呈线性增长。 链式复制的架构下，复制链越长，复制链末端的 readonly slave 和 master 之间的同步延迟就越大， 考虑到读写分离主要使用在对一致性要求不高的场景下，这个缺点一般可以接受。但是如果复制链中 的某个节点异常，会导致下游的所有节点数据都会大幅滞后，更加严重的是这可能带来全量同步，并 且全量同步将一直传递到复制链的末端，这会对服务带来一定的影响，为了解决这个问题，读写分离 的 redis 都使用阿里云优化后的 binlog 复制版本，最大程度的降低全量同步的概率。 4 结合上述的讨论和比较， redis 的读写分离选择链式复制的架构。 透明、兼