毕业一年多,整理了下Redis使用规范

Redis使用规范

在项目中,redis属于高频使用,在使用中,遇到了各种各样的redis问题,针对自身情况梳理了一个redis使用规范。

键名设计
key名设计
  • 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符)

  • 建议风格一致

这里指的是key的书写风格,建议同时大驼峰、同时小驼峰或者下划线;是项目级别的统一

eg:userAdmin UserAdmin user_admin

  • key不能太长也不能太短,键名越长越占资源,太短可读性太差

  • key 单词与单词之间以分开

之所以用:来进行间隔区分是因为现在市面上的redis可视化工具,:比较容易进行下级选择

  • redis使用的时候注意命名空间,一个项目一个命名空间,项目内业务不同命名空间也不同

一般情况下:

  • 第一段放置项目名或缩写 如 project
  • 第二段把表名转换为key前缀 如, user:
  • 第三段放置用于区分区key的字段,对应mysql中的主键的列名,如userid
  • 第四段放置主键值,如18,16
    结合起来 PRO:USER:UID:18 就很清晰
value设计
  • 拒绝大key操作

禁用超过10K的string大key(虽然redis支持512MB大小的string),如果1mb的key每秒重复写入10次,就会导致写入网络IO达10MB。

  • 设计key时使用合适的数据类型(在资源利用和性能之间作平衡)

例如:将一个普通字符串弄成hash类型进行存储这是不合理的

  • 控制key的生命周期

例如:key设置为永不过期是不合理的,也不建议过期时间全部一样,避免key大面积失效,mysql被打满

  • 控制value长度

比如string类型,如果value为’8个字节的长整型’则内部使用int类型,如果value为’小于等于39个字节的字符串’则内部使用embstr类型,如果value为’大于39个字节的字符串’则内部使用raw类型。这样能很好的利用redis的性能。

数据按需存储

不需要的数据千万不要存储在redis,只会浪费内存空间

命令使用
  • 禁止使用keys、flushall、hmgetall等命令

为防止业务研发的误操作,通常可以在交付redis实例之前将默认命令rename掉;而真正需要删除或者遍历key时可以使用scan家族命令

  • 慎用hgetall、lrange、smembers、zrange等命令

除非业务场景需要,尽量不要使用这些命令。如果没有控制好会导致操作量过大,形成阻塞。

项目实战
  • 项目redis使用问题

当前的使用方式是,每个接入的应用要配置核心项目的redis配置。这样是不合理的,核心项目的redis应该只能在核心项目中使用,对外应该是提供api接口或者rpc进行访问。

  • 注意key的过期时间设置

在报名等高峰期的时候,key值设置过短容易造成缓存穿透,导致大量请求直接打到mysql数据库。

  • 提防缓存穿透

空值也应该被缓存,经常使用会只给有数据的结果进行缓存,结果导致空数据无法缓存,相同查询直接每次都到达数据库,所以

  • 不建议将redis做为消息队列

如没有非常特殊的需求,严禁将 Redis 当作消息队列使用。redis 当作消息队列使用,会有容量、网络、效率、功能方面的多种问题。
如需要消息队列,可使用高吞吐的 Kafka 或者高可靠的 RocketMQ,nsq,(花园同步有时间前后要求,且量不大才使用的)。

查询使用
线上Redis禁止使用Keys正则匹配操作

redis是单线程处理,在线上Key数量较多时,操作效率极低【时间复杂度为O(N)】,该命令一旦执行会严重阻塞线上其它命令的正常请求,而且在高QPS情况下会直接造成redis服务崩溃!如果有类似需求,可以使用scan命令代替。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值