Redis

关注公众号 jb51net

关闭
首页 > 数据库 > Redis > Redis 键值设计

Redis 键值设计使用总结

作者:逆风飞翔的小叔

这篇文章主要介绍了Redis键值设计的使用总结,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

前言

对redis的使用,想必做过后端开发的同学都不陌生,redis为key/value非关系型数据库,使用起来简单高效,支持的数据类型也比较丰富,几乎在日常开发中没有不涉及的;

但如果对redis使用比较深入的话,还需要综合考虑多方面的因素,比如使用redis时如何兼具高效与性能,如何设计合理的key以达到存取时最高效等等,这都是应该考虑的,下面结合redis中一个比较简单但也容易的问题,关于redis的键值设计做一个全面的探讨;

Redis使用中不规范的现象

Redis 使用业务场景推荐与建议

如何设计出优雅的key

可以这么说,线上关于redis的性能优化这个问题上,不合理的key的设计经常是引发问题的根因,究其本质,就个人看到的情况来说,大多数同学在对redis使用过程中,对于key的设计几乎是没有什么概念的,因为大多数同学使用的场景就是 key/val ,对应的数据结构就是 字符串key/字符串val;

稍微对redis有更深入的了解的同学,在进行存储时,可能会知道 key的设计尽量短一点,中间最好有层次感,最好以 : 进行分割 ......

那么如何才能设计出比较优雅的key呢?下面结合小编实际使用中的经验以及踩过的坑,来具体谈谈;

一、遵循如下几个最佳实践约定

  1. 遵循基本格式:[业务名称]:[数据名]:[id];
  2. key的长度不超过44字节;
  3. 不要包含特殊字符;

关于上面几条建议,这样做有如下几点好处:

推荐值:

二、尽量避免bigkey

1、什么是bigkey呢

BigKey通常以Key的大小和Key中成员的数量来综合判定,例如:

2、BigKey的危害

网络阻塞

数据倾斜

Redis阻塞

CPU压力

3、如何发现BigKey

在安装的机器上执行 redis-cli --bigkeys命令

通过scan扫描

使用第三方工具

使用网络监控

三、使用恰当的数据类型

正如上面所说,很多初次使用redis的同学,对于很多业务场景,都是一个key/val的简单的结构搞定,而不会深入思考这样做是否合理,或者说这样做以后会不会引发相关的性能方面的问题;

对于这个问题,从根本上来说,需要深入了解并掌握redis的常用的数据类型,在这个基础上,才能针对不同的业务场景,设计出高效的存储存储结构数据;

让我们思考一下,如何缓存用户对象列表这样的数据呢?

优点:存取方便,简单粗暴,存取时只需要做下json和对象的互转即可;

缺点:数据耦合,不够灵活,一旦对象新增了字段或删减了字段,缓存重建的成本非常大;

优点:对内存的占用小,操作高效;

缺点:获取到val之后,需要进一步查库才能得到完整的对象;

方案3:使用hash结构,缓存对象,数据如下所示;

优点:底层使用ziplist,空间占用小,可以灵活访问对象的任意字段;

缺点:编码上相对复杂;

Redis 缓存在实际应用中的使用建议

使用业务规范

不管是redis,还是其他开发中使用到的中间件,具体到开发使用时,最好都应该提前制定出一套合理的规范,这个规范应该是大多数开发人员认可并在实践中得到检验,且能有效规避一些问题的,一旦指定为规范,应该成为指导内部开发人员日常的规则,这里提如下几点:

以上就是Redis 键值设计使用总结的详细内容,更多关于Redis 键值设计的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文