Redis 很屌,不懂使用规范就糟蹋了

发布日期:2022-08-07 05:02    点击次数:164

码哥,昨天我被公司 Leader 批评了。

我在单身红娘婚恋类型互联网公司工作,在双十一推出下单就送女朋友的活动。

谁曾想,凌晨 12 点之后,用户量暴增,出现了一个技术故障,用户无法下单,当时老大火冒三丈!

经过查找发现 Redis 报 Could not get a resource from the pool。

获取不到连接资源,并且集群中的单台 Redis 连接量很高。

于是各种更改最大连接数、连接等待数,虽然报错信息频率有所缓解,但还是持续报错。

后来经过线下测试,发现存放 Redis 中的字符数据很大,平均 1s 返回数据。

码哥,可以分享下使用 Redis 的规范么?我想做一个唯快不破的真男人!

通过 Redis 为什么这么快?这篇文章我们知道 Redis 为了高性能和节省内存费劲心思。

所以, 现代灯具只有规范的使用 Redis,才能实现高性能和节省内存,否则再屌的 Redis 也禁不起我们瞎折腾。

Redis 使用规范围绕如下几个纬度展开:

键值对使用规范; 命令使用规范; 数据保存规范; 运维规范。 键值对使用规范

有两点需要注意:

好的 key 命名,才能提供可读性强、可维护性高的 key,便于定位问题和寻找数据。 value要避免出现 bigkey、选择高效的序列化和压缩、使用对象共享池、选择高效恰当的数据类型(可参考《Redis 实战篇:巧用数据类型实现亿级数据统计》)。 key 命名规范规范

的 key命名,在遇到问题的时候能够方便定位。Redis 属于 没有 Scheme的 NoSQL数据库。

所以要靠规范来建立其 Scheme 语意,精品集萃就好比根据不同的场景我们建立不同的数据库。

敲黑板

把「业务模块名」作为前缀(好比数据库 Scheme),通过「冒号」分隔,再加上「具体业务名」。

这样我们就可以通过 key 前缀来区分不同的业务数据,清晰明了。

总结起来就是:「业务名:表名:id」

比如我们要统计公众号属于技术类型的博主「码哥字节」的粉丝数。

set 公众号:技术类:码哥字节 100000 

码哥,key 太长的话有什么问题么?

key 是字符串,底层的数据结构是 SDS,SDS 结构中会包含字符串长度、分配空间大小等元数据信息。

字符串长度增加,SDS 的元数据也会占用更多的内存空间。

所以当字符串太长的时候,我们可以采用适当缩写的形式。

不要使用 bigkey❝

码哥,我就中招了,导致报错获取不到连接。

因为 Redis 是单线程执行读写指令,如果出现bigkey 的读写操作就会阻塞线程,降低 Redis 的处理效率。

bigkey包含两种情况:

键值对的 value很大,比如 value保存了 2MB的 String数据; 键值对的 value是集合类型,元素很多,比如保存了 5 万个元素的 List 集合。

虽然 Redis 官方说明了 key和string类型 value限制均为512MB。

防止网卡流量、慢查询,string类型控制在10KB以内,hash、list、set、zset元素个数不要超过 5000。

码哥,如果业务数据就是这么大咋办?比如保存的是《金瓶梅》这个大作。

我们还可以通过 gzip 数据压缩来减小数据大小:

/**  * 使用gzip压缩字符串  */ public static String compress(String str) {     if (str == null 


栏目分类



Powered by 重庆递乐搬家服务有限公司 @2013-2022 RSS地图 HTML地图

Copyright 站群系统 © 2013-2022 365建站器 版权所有