Redis跨云迁移实践

背景

Redis是使用最广泛的缓存数据库,各家公有云厂商都有提供Redis服务,虽然都是Redis服务,但是不同云厂商的架构与性能规格都有差异,在跨云迁移的时候,需要谨慎评估,避免迁移后出现性能问题。

前提条件

本文的对比都是基于Proxy模式的Redis集群的,当前主流的Redis集群是Proxy模式;Redis原生集群对开发者来说,比使用Proxy模式集群要更复杂,提供的云厂家也相对较少,因此还是起步阶段。

架构与性能规格对比

TBD

迁移评估项

在搬迁评估时候,除了要了解不同云之间Redis架构差异之外,还需要了解清楚Redis的使用场景,下面一些指标项是常用来判断Redis使用场景。

内存容量

根据Key写入数量/频度,TTL时常,是否显示删除判断容量增长情况,避免容量满。 当Redis内存容量满时,再次写入则会触发淘汰Key操作。同时由于内存满,可能导致系统资源不足,淘汰Key的操作会很耗时,从而导致写入超时。

是否落盘

数据需要落盘的话,需要确认 appendfsync=everysec 如果开启,底下磁盘是否是SSD;否则在高QPS写的场景,如果不是SSD盘,可能会导致应用访问Redis时延增加,极端情况会访问超时。

数据是否可重生成

如果数据可以重生成,则不需要迁移数据。

如果数据不能重生成,那么意味着需要迁移数据。当前并没有Redis在线迁移的工具或服务(DRS服务对Redis支持还不完善),因此需要业务代码配合完成迁移,根据业务情况讨论迁移方案。 典型的方法有:

  • 业务代码双写
  • 如果重复Key值可以覆盖,则可以写一个工具从源库读,写到目的库,然后在某个时间点,短暂停业务切换库
  • 简单粗暴的是停业务迁移

QPS

QPS是选择Redis规格的主要依据之一,有的场景是数据量很小,QPS很高,由于主备版本的最大QPS有限,如果需要的QPS超过了主备版本的QPS最大值,那么也得上集群版本。 内存很小,QPS很高的场景,也是小规格集群的主要场景之一。

读写QPS占比

QPS指标需要区分读/写,写QPS很高的话要注意 AOF REWRITE,在执行 AOF REWRITE 时再写入的话,时延会变高,极端情况下会导致访问超时。 参考连接

并发连接数

根据要求的并发连接数选定对应的规格。如果是短链接方式访问,要特别注意。

是否有TTL设置过长会导致内存满

可能有一些Key的TTL设置的很长(如一个月),且没有主动删除机制,那么就可能会导致内存满,从而触发Key淘汰策略,这时候再写入可能会超时。

是否使用Pipeline

在QPS很高的场景下,使用Pipeline相比较单个Key操作,效率和性能都有很大提升。但是需要限定Pipeline中的命令数量,当前Codis Proxy默认的 session_max_pipeline=10000 ,建议不要超过此值。 同时还需要评估一次Pipeline返回的数据量。

是否使用多DB

有一些云厂商(如阿里云)支持Redis集群有多DB特性,不同DB中的Key值可以相同。Codis原生集群是不支持多DB的。

长连接or短连接

短连接需要特别关注连接数这个指标。如果是短链接,需要关注内存参数本地端口、最大句柄数等值是否调优。

Codis Proxy 与 Redis Server 调优参数

对于不同的使用场景,特别针对大客户,云厂商可能有给定制过某些参数,因此获取到迁移源实例的Redis Server,对比新实例的参数,如果有差异与客户讨论是否是当时解决什么问题而配置的。把差异的参数都核对完。