Redis使用规范及调优策略

朴灿烈づ我的快乐病毒、 2023-01-14 09:58 83阅读 0赞

**参考文章：**[Redis性能调优策略][Redis]

[redis调优的实战经验 - 大叔据 - 博客园][redis_ - _ -]

[优化 Redis 的使用策略][Redis 1]

**其它资料参考：**

>  *  **[带有详细注释的 Redis 3.0 代码][Redis 3.0]**
>  *  **[《Redis 设计与实现》][Redis 2]**
>  *  **[《Redis 设计与实现》图片集][Redis 3]**
>  *  **[Redis command][]**
>  *  **[Redis 命令参考][Redis 4]**

> 本文根据redis的info命令查看redis的内存使用情况以及state状态，来观察redis的运行情况以及需要作出的相应优化。

# 一、Redis使用规范 #

## 1.1 Redis Key 的命名策略 ##

> Redis 是 K-V 形式的缓存数据库，每一个需要缓存的 Object 都需要唯一的 Key 来标识。但是，我们日常在做开发的时候，经常会出现一个公司或者部门之间共用一个 Redis 集群的情况。所以，这就有可能会造成 Key 冲突，引发数据被覆盖的问题（即使是同一个部门，也可能存在不同的研发人员使用了同名的 Key）。

*  **根据业务名称命名 - 不建议**

一个项目中，相似的业务是很常见的，所以，如果不同的研发人员使用了同名的 Key，就会导致系统的 bug。同时，如果不同的项目组在共同使用一个 Redis 集群，也会发生这样的问题。例如：

127.0.0.1:6379> set name qinyi
    OK
    # 同一个项目中的不同业务使用了同名的 key （不同的研发人员共同开发造成）
    127.0.0.1:6379> lpush name qinyi imooc
    (error) WRONGTYPE Operation against a key holding the wrong kind of value
    127.0.0.1:6379>

*  **在业务名称之前加上项目的名称 - 不建议**

这样做可以大概率的避免不同的项目引起的 Key 冲突问题，但是，仍然不能避免同一个项目中的不同业务。例如：

# a、b 两个项目在使用 Redis 时，各自以项目的名称为 Key 的前缀
    127.0.0.1:6379> set a-name qinyi
    OK
    127.0.0.1:6379> set b-name imooc
    OK
    # 仍不能避免同一个项目中的不同业务使用了同名的 key
    127.0.0.1:6379> lpush a-name qinyi imooc
    (error) WRONGTYPE Operation against a key holding the wrong kind of value
    127.0.0.1:6379>

*  **Key = 项目名称-业务名称-时间戳 - 建议**

这种命名 Key 的方式是比较好的，相比于上一种方式，多增加了一个时间戳标识。这里的含义就是与不同的开发人员定义相同时间戳的概率很低很低。具体时间戳的精度可以根据业务的实际情况选择，比如：天、小时等等。例如：

# Key 中添加天级的时间戳来避免 Key 冲突的问题
    127.0.0.1:6379> set a-name-20190314 qinyi
    OK
    127.0.0.1:6379> lpush a-name-20190315 qinyi imooc
    (integer) 2
    127.0.0.1:6379>

## 1.2 过期时间的设定 ##

在使用 Redis 时，绝大多数情况都需要给 Key 设定过期时间，这个是非常有必要的。原因如下：

>  *  作为缓存，加快程序的执行速度。但是缓存的 Object 很可能是会经常变化的，不要长期驻留在 Redis 中
>  *  当 Redis 的内存使用超过一个阈值（可以自定义）时，会触发 Redis 的缓存淘汰策略，此时的 LRU 过程是非常慢的。极大的影响 Redis 的性能

**Redis有四个命令可以设置键的存活时间或过期时间：**

>  *  expire：用于设置key还剩余多少秒过期
>  *  pexpire：用于设置key还有多少毫秒过期
>  *  expireat：用于设置key的过期时间（到期的具体秒数时间戳）
>  *  pexpireat：用于设置key的过期时间（到期的具体毫秒时间戳）

所以，在保存 KV 时，最好是设定过期时间。例如：

127.0.0.1:6379> set name qinyi
    OK
    127.0.0.1:6379> expire name 30
    (integer) 1
    127.0.0.1:6379> ttl name
    (integer) 25
    127.0.0.1:6379>

关于 Redis 设定过期时间（这里包含过期键的删除）需要知道：

>  *  Redis 对于设定过期时间的键是怎么保存的
>  *  Redis 键的过期删除策略

## 1.3 数据结构的选择 ##

Redis 常用的数据结构一共有五种：string、hash、list、set、zset（sorted set）。可以发现，大多数场景下使用 string 都可以去解决问题。但是，这并不一定是最优的选择。下面，简单说明下它们各自的适用场景：

>  *  string：单个的缓存结果，不与其他的 KV 之间有联系
>  *  hash：一个 Object 包含有很多属性，且这些属性都需要单独存储。注意：这种情况不要使用 string，因为 string 会占据更多的内存
>  *  list：一个 Object 包含很多数据，且这些数据允许重复、要求有顺序性
>  *  set：一个 Object 包含很多数据，不要求数据有顺序，但是不允许重复
>  *  zset：一个 Object 包含很多数据，且这些数据自身还包含一个权重值，可以利用这个权重值来排序

另外，Redis 还提供了一些特别的数据结构，用于一些特殊的场景。例如：Geo、HyperLogLog

>  *  Geo：LBS 相关的应用，可以参考：[Redis Geo][]
>  *  HyperLogLog：允许存在误差的基数统计，可以参考：[Redis HyperLogLog][]

## 1.4 持久化机制的选择 ##

Redis 提供了两种持久化机制：RDB 和 AOF。

>  *  **RDB**：在指定的时间间隔内将内存中的数据快照写入磁盘，实际操作过程是 fork 一个子进程，先将数据写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储
>  *  **AOF**：以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录

关于这两种持久化方式的优点不做解释，可以根据其实现形式得出结论。下面，分析下它们各自的缺点。

**RDB 的缺点**

>  *  如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失
>  *  由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟

**AOF 的缺点**

>  *  对于相同数量的数据而言，AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据时的速度比 AOF 的恢复速度要快
>  *  由于同步策略的不同，AOF 在运行效率上往往会慢于 RDB

**总结：**

> 二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（AOF），还是愿意写操作频繁的时候，不启用备份来换取更高的性能。

## 1.5 不要使用 Redis 存储单 Key 大数据 ##

这里所说的大数据，不是说不使用 Redis 存储更多的数据，而是说单个 KV 很大的情况。这里最核心的原因是：Redis 是单进程单线程的应用。这种工作方式在操作过程上避免了线程切换的耗时，而且不需要考虑线程安全，无需获取锁、释放锁等操作，是非常简单、直接的。但是：

>  *  Redis 的单线程工作机制，无法用多核并行处理。如果遇到 IO 量大的操作，出现等待 IO 的情况会增多，即使 Redis 底层用的是 IO 多路复用技术，IO 的事件句柄也是要占用资源的
>  *  Redis 的持久化需要将数据保存下来，KV 的数据量很大，也会影响持久化的执行

# 二、Redis调优策略 #

## 2.1 memory参数 ##

#used_memory=实际缓存占用的内存+Redis自身运行所占用的内存(如元数据、lua)。
    #这个值是由Redis使用内存分配器分配的内存，不包括内存碎片浪费的内存。
    used_memory:13409011624 
    
    #从操作系统上显示已经分配的内存总量。
    used_memory_rss:13740019719  
    
    #内存使用的峰值大小
    used_memory_peak:13409011624  
    
    #系统总内存
    total_system_memory:33567678464  
    
    #Lua脚本引擎所使用的内存大小。
    used_memory_lua:37888  
    
    #最大可用内存(可配置，默认为total_system_memory)
    maxmemory:0  
    
    #淘汰机制,noneviction为禁止淘汰数据
    maxmemory_policy:noeviction  
    
    #内存碎片率
    mem_fragmentation_ratio:1.02;  
    
    #编译时指定的Redis内存分配器，可以是libc、jemalloc、tcmalloc。
    mem_allocator:jemalloc-4.0.3;
    
    #自启动起Redis服务处理命令的总数 
    total_commands_processed:3500

## 2.2 used\_memory 过大导致的问题 ##

### 2.2.1 引发内存交换 ###

> 当Redis内存使用率超过可用内存(maxmemory可配置)的95%时，操作系统会进行内存与swap空间数据交换。 **把内存中旧的或不再使用的内容写入硬盘上即Swap分区，以便腾出新的物理内存给新页或活动页(page)使用**。 在硬盘上进行读写操作要比在内存上进行读写操作，时间上慢了近 **5个数量级**，内存是0.1μs单位、而硬盘是10ms。如果Redis进程上发生内存交换，那么Redis和依赖Redis上数据的应用会受到严重的性能影响。

### 2.2.2 rdb持久化风险 ###

> 在没有开启持久化的情况下， **redis宕机或者内存使用率超过95%会有丢数据的风险**。若使用快照(rdb)持久化，Redis会fork一个子进程把当前内存中的数据完全复制一份写入到硬盘上( **fork使用的内存和redis当前使用的内存会一样多**)。因此若是当前使用内存 **超过可用内存的45%时**触发快照功能，那么此时进行的内存交换会变的非常危险(可能会丢失数据)。 倘若在这个时候实例上有大量频繁的更新操作，问题会变得更加严重。

## 2.3 避免used\_memory 过大 ##

*  **尽可能的使用Hash数据结构**。

> 因为Redis在储存小于100个字段的Hash结构上，其存储效率是非常高的。所以 **在不需要集合(set)操作或list的push/pop操作的时候，尽可能的使用Hash结构**。比如，在一个web应用程序中，需要存储一个对象表示用户信息，使用单个key表示一个用户，其每个属性存储在Hash的字段里，这样要比给每个属性单独设置一个key-value要高效的多。 通常情况下倘若有数据使用string结构，用多个key存储时，那么应该转换成单key多字段的Hash结构。 如上述例子中介绍的Hash结构应包含，单个对象的属性或者单个用户各种各样的资料。Hash结构的操作命令是HSET(key, fields, value)和HGET(key, field)，使用它可以存储或从Hash中取出指定的字段。

*  **设置key的过期时间**。

> 一个减少内存使用率的简单方法就是， **每当存储对象时确保设置key的过期时间**。倘若key在明确的时间周期内使用或者旧key不大可能被使用时，就可以用Redis过期时间命令(expire,expireat, pexpire, pexpireat)去设置过期时间，这样Redis会在key过期时自动删除key。 假如你知道每秒钟有多少个新key-value被创建，那可以调整key的存活时间，并指定阀值去限制Redis使用的最大内存。

*  **回收key**。

> 在Redis配置文件Redis.conf中， **通过设置“maxmemory”属性的值可以限制Redis最大使用的内存**，修改后重启实例生效。 也可以使用客户端命令config set maxmemory 去修改值，这个命令是立即生效的，但会在重启后会失效，需要使用config rewrite命令去刷新配置文件。
> 
> 1.  若是启用了Redis快照功能，应该设置“maxmemory”值为系统可使用内存的45%，因为快照时需要一倍的内存来复制整个数据集，也就是说如果当前已使用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其他的开销。
> 2.  如果没开启快照功能，maxmemory最高能设置为系统可用内存的95%。

*  **淘汰策略**

> 当内存使用 **达到设置的最大阀值**时，需要选择一种 **key的回收策略**，可在Redis.conf配置文件中修改“maxmemory-policy”属性值。
> 
>  *  若是Redis数据集中的key都设置了过期时间，那么“volatile-ttl”策略是比较好的选择。
>  *  但如果key在达到最大内存限制时没能够迅速过期，或者根本没有设置过期时间。那么设置为“allkeys-lru”值比较合适，它允许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。

**Redis还提供了一些其他淘汰策略，如下**：

volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据。
    
    volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰。
    
    volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰。
    
    allkeys-lru：使用LRU算法从所有数据集合中淘汰数据。
    
    allkeys-random：从数据集合中任意选择数据淘汰
    
    no-enviction：禁止淘汰数据。

> 通过设置maxmemory为系统可用内存的45%或95%(取决于持久化策略)和设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过期设置)，可以比较准确的限制Redis最大内存使用率， **在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换**。倘若你担心由于限制了内存使用率导致丢失数据的话，可以设置noneviction值禁止淘汰数据。

## 2.4 used\_memory\_rss 过大解决办法 ##

> 当mem\_fragmentation\_ratio远大于1时即used\_memory\_rss/used\_memory（稍大于1正常）,说明redis中存在大量的内存碎片,一个比较好的解决办法就是重启redis，这里需要注意的是 **如果用的是aof持久化，那么重启之前要进行rewriteaof操作，否则会无效**。还有可以指定Redis使用的内存分配器，一般管理员不推荐，麻烦而且要重新编译。

[Redis]: https://www.cnblogs.com/liconglong/p/14370026.html
[redis_ - _ -]: https://www.blogarama.com/frame?siteId=231406&postid=27087171
[Redis 1]: https://zhuanlan.zhihu.com/p/59380099
[Redis 3.0]: https://link.zhihu.com/?target=https%3A//github.com/huangz1990/redis-3.0-annotated
[Redis 2]: https://link.zhihu.com/?target=http%3A//redisbook.com/
[Redis 3]: https://link.zhihu.com/?target=http%3A//1e-gallery.redisbook.com/
[Redis command]: https://link.zhihu.com/?target=https%3A//redis.io/commands
[Redis 4]: https://link.zhihu.com/?target=http%3A//redisdoc.com/index.html
[Redis Geo]: https://zhuanlan.zhihu.com/p/57963851
[Redis HyperLogLog]: https://zhuanlan.zhihu.com/p/58358264