加餐(六)| Redis的使用规范小建议
蒋德钧
该思维导图由 AI 生成,仅供参考
你好,我是蒋德钧。
今天的加餐,我们来聊一个轻松点儿的话题,我来给你介绍一下 Redis 的使用规范,包括键值对使用、业务数据保存和命令使用规范。
毕竟,高性能和节省内存,是我们的两个目标,只有规范地使用 Redis,才能真正实现这两个目标。如果说之前的内容教会了你怎么用,那么今天的内容,就是帮助你用好 Redis,尽量不出错。
好了,话不多说,我们来看下键值对的使用规范。
键值对使用规范
关于键值对的使用规范,我主要想和你说两个方面:
key 的命名规范,只有命名规范,才能提供可读性强、可维护性好的 key,方便日常管理;
value 的设计规范,包括避免 bigkey、选择高效序列化方法和压缩方法、使用整数对象共享池、数据类型选择。
规范一:key 的命名规范
一个 Redis 实例默认可以支持 16 个数据库,我们可以把不同的业务数据分散保存到不同的数据库中。
但是,在使用不同数据库时,客户端需要使用 SELECT 命令进行数据库切换,相当于增加了一个额外的操作。
其实,我们可以通过合理命名 key,减少这个操作。具体的做法是,把业务名作为前缀,然后用冒号分隔,再加上具体的业务数据名。这样一来,我们可以通过 key 的前缀区分不同的业务数据,就不用在多个数据库间来回切换了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Redis使用规范小建议 本文总结了蒋德钧在《Redis的使用规范小建议》中分享的关于Redis的使用规范。文章围绕着高性能访问和节省内存空间这两个目标,从键值对使用、命令使用和数据保存三个方面介绍了11个规范。其中,强调了键值对命名规范、避免使用bigkey、高效序列化和压缩方法的重要性,以及将不同业务数据分别存储在不同的Redis实例中并设置数据的过期时间。此外,还提到了禁用部分命令、慎用MONITOR命令和全量操作命令的建议。作者还对规范进行了分类,包括强制类别、推荐类别和建议类别。最后,作者鼓励读者熟练掌握这些使用规范,并将其应用到实际的Redis使用场景中,以提高Redis的使用效率。 这篇文章对于读者快速了解Redis的使用规范提供了全面的概览,涵盖了技术特点和实际应用建议,对于想要提升Redis应用性能的技术人员具有很高的参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》,新⼈⾸单¥68
《Redis 核心技术与实战》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
- Kaito我总结的 Redis 使用规范分为两大方面,主要包括业务层面和运维层面。 业务层面主要面向的业务开发人员: 1、key 的长度尽量短,节省内存空间 2、避免 bigkey,防止阻塞主线程 3、4.0+版本建议开启 lazy-free 4、把 Redis 当作缓存使用,设置过期时间 5、不使用复杂度过高的命令,例如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 6、查询数据尽量不一次性查询全量,写入大量数据建议分多批写入 7、批量操作建议 MGET/MSET 替代 GET/SET,HMGET/HMSET 替代 HGET/HSET 8、禁止使用 KEYS/FLUSHALL/FLUSHDB 命令 9、避免集中过期 key 10、根据业务场景选择合适的淘汰策略 11、使用连接池操作 Redis,并设置合理的参数,避免短连接 12、只使用 db0,减少 SELECT 命令的消耗 13、读请求量很大时,建议读写分离,写请求量很大,建议使用切片集群 运维层面主要面向的是 DBA 运维人员: 1、按业务线部署实例,避免多个业务线混合部署,出问题影响其他业务 2、保证机器有足够的 CPU、内存、带宽、磁盘资源 3、建议部署主从集群,并分布在不同机器上,slave 设置为 readonly 4、主从节点所部署的机器各自独立,尽量避免交叉部署,对从节点做维护时,不会影响到主节点 5、推荐部署哨兵集群实现故障自动切换,哨兵节点分布在不同机器上 6、提前做好容量规划,防止主从全量同步时,实例使用内存突增导致内存不足 7、做好机器 CPU、内存、带宽、磁盘监控,资源不足时及时报警,任意资源不足都会影响 Redis 性能 8、实例设置最大连接数,防止过多客户端连接导致实例负载过高,影响性能 9、单个实例内存建议控制在 10G 以下,大实例在主从全量同步、备份时有阻塞风险 10、设置合理的 slowlog 阈值,并对其进行监控,slowlog 过多需及时报警 11、设置合理的 repl-backlog,降低主从全量同步的概率 12、设置合理的 slave client-output-buffer-limit,避免主从复制中断情况发生 13、推荐在从节点上备份,不影响主节点性能 14、不开启 AOF 或开启 AOF 配置为每秒刷盘,避免磁盘 IO 拖慢 Redis 性能 15、调整 maxmemory 时,注意主从节点的调整顺序,顺序错误会导致主从数据不一致 16、对实例部署监控,采集 INFO 信息时采用长连接,避免频繁的短连接 17、做好实例运行时监控,重点关注 expired_keys、evicted_keys、latest_fork_usec,这些指标短时突增可能会有阻塞风险 18、扫描线上实例时,记得设置休眠时间,避免过高 OPS 产生性能抖动2020-11-1819257
- zhou还有一个规范:不要把 Redis 当数据库使用2020-11-18428
- 独自等待【在集合元素个数小于一定的阈值时,会使用内存紧凑型的底层数据结构进行保存,从而节省内存。例如,假设 Hash 集合的 hash-max-ziplist-entries 配置项是 1000,如果 Hash 集合元素个数不超过 1000,就会使用 ziplist 保存数据。紧凑型数据结构虽然可以节省内存,但是会在一定程度上导致数据的读写性能下降】 请问这个怎么理解,内存连续读写性能不应该更好吗?2020-11-1824
- escray好像没怎么看到过 bigkey 的标准定义,之前误以为真的是"key"太大,后来才发现是 value 太大。 键值对使用规范 - key 命名规范:业务名作前缀,冒号分隔,加业务数据名,尽量避免数据库切换。key 的长度最好不超过 31(SDS结构元数据大小 1 字节) - 避免使用 bigkey:String 类型的数据控制在 10KB 一下,集合类型的元素个数控制在 1 万以内。 - 使用高效的序列化和压缩方法:protostuff 和 kryo 优于 Java 内置的 java-build-in-serializer;如果使用 XML 或者 JSON 可以考虑压缩,snappy 或 gzip - 使用整数对象共享池:在满足业务数据需求的前提下,尽量用整数 数据保存规范 - 使用 Redis 保存热数据 - 不同的业务数据分实例存储 - 保存数据时,设置过期时间 - 控制 Redis 实例的容量,2~6 GB 命令使用规范 - 线上禁用部分命令:KEYS、FLUSHALL、FLUSHDB - 慎用 MONITOR - 慎用全量操作命令 课代表 @Kaito 大神的 Redis 使用规范值得收藏。2021-03-223
- camel请问为什么特别强调sds元数据的大小?key超过32,元数据才从1到3,相对于本身key大小而言元数据不是才占很小比例吗?2021-09-1511
- aoe非常实用,感谢老师2021-04-171
- 叶子。从 Redis 3.2 版本开始,当 key 字符串的长度增加时,SDS 中的元数据也会占用更多内存空间 请问这句话怎么理解,之前讲SDS的时候说的好像是 长度和实际分配长度分别占用4B?2020-11-1821
- 飞龙实际业务中遇到过一个困扰,就是项目起初只是记录每个用户的一个标识,用了HASH,但是随便项目的飞速发展,用户数量到了5000W,导致 这个HASH里的元素上千万级别了,单这一个就占了1个多G的内存,后面也不太好根据业务分散2022-08-24归属地:广东2
- camel请问老师,如果一个hash非常大,比如超过10w个记录,避免了hgetall也会导致阻塞很久吗? 也就是说hget操作的性能与hash.size有没有关系,是什么复杂度的关系?(算法层面上能理解的是应该没关系,因为hash的查询操作是O(1)复杂度)2021-09-15
- 悟空聊架构总结得很棒,还需要在实践中不断地总结。谢谢老师!2021-05-141
收起评论