为了账号安全,请及时绑定邮箱和手机立即绑定

优化 Redis 的使用策略

2019.03.15 17:08 1333浏览

Redis 学习资料整理

想要系统的学习 Redis 的同学,可以阅读下面整理的学习资料。内容非常全面,几乎涵盖了 Redis 的各个特性与使用方法。

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>

过期时间的设定

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

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

所以,在保存 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 键的过期删除策略

数据结构的选择

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

持久化机制的选择

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

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

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

RDB 的缺点

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

AOF 的缺点

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

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

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

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

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

·······························
欢迎关注课程:

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

7人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消