团队内部redis使用规范

2019/03/20 发布  ·  次阅读  ·  本文 1629 字  ·  读完需要 5 分钟

团队内部Redis使用约定

目的

为了避免再次出现因redis使用不当,而造成异常影响业务,以及方便后期运维,故而经团队内部人员协商,出具redis使用规范,通过规范使用更好、更高效,更安全的使用redis缓存。

目前情况

  • redis命名不规范,各种命名规则混合使用
  • redis被用于持久化存储数据,redis数据有丢失风险,无重新加载方案
  • redis存储的key,未设置过期时间

规范定义

关于文档中「能愿动词」的使用,参考psr使用规范的定义

为了避免歧义,文档大量使用了「能愿动词」,对应的解释如下:

  • 必须 (MUST):绝对,严格遵循,请照做,无条件遵守;
  • 一定不可 (MUST NOT):禁令,严令禁止;
  • 应该 (SHOULD) :强烈建议这样做,但是不强求;
  • 不该 (SHOULD NOT):强烈不建议这样做,但是不强求;
  • 可以 (MAY) 和 可选 (OPTIONAL) :选择性高一点,在这个文档内,此词语使用较少;

键值设计

  1. redis key命名应该具有可读性以及可管理行,不该使用含义不清的key以及特别长的key名;
  2. redis key命名必须全部由小写字母、数字、英文点号(.)和英文半角冒号(:)组成,必须以英文字母开头;
  3. redis key命名必须按照模块区分前缀,具体模块定义参照上述模块划分中的内容,逻辑含义段必须使用英文半角冒号(:)分割,单词之间必须使用英文半角点号(.)分割,一定不可使用殊字符(下划线、空格、换行、单双引号以及其他转义字符等);
  4. redis key命名必须以key所代表的value类型结尾,见到key即可知道存储数据类型,以提高可读性;
  5. 总结,命名规范为 业务模块名:业务逻辑含义:其他:value类型
    user:uid:1:string
    

业务规范

  1. redis应该定位为缓存数据,除特殊需求外,聊天等

  2. redis,应该设置过期时间

  • redis定位为缓存cache使用时,对于存放的key,应该使用expire设置过期时间;
  • 若不设置的话,这些key会一直占用内存不释放,随着时间的推移会越来越大,直到达到服务器的内存上线,导致宕机等恶略影响;
  • 对于key的超时时长设置,可根据业务需求自行评估,并非越长越好;
  • 某些业务的确需要长期有效,可以在每次设置时,设置超时时间,让超时时间顺延;
  1. redis的使用,应该考虑冷热数据分离,不该将所有数据全部放到redis中,对于使用不频繁,且无关的日志等存入mysql,或正常的日志文件系统中

redis的数据存储全部都是在内存中的,成本昂贵。应该根据业务只将高频热数据存储到redis中,对于低频冷数据可以使用MySQL/MongoDB等基于磁盘的存储方式,不仅节省内存成本,而且数据量小在操作时速度更快、效率更高

  1. redis有数据丢失风险,程序处理数据时,应该考虑丢失后的重新加载过程

使用redis时,要考虑丢失数据的风险,项目架构时需要考虑到相应解决方案,程序需要处理如果redis数据丢失时重新可进行重新加载

  1. 对于必须要存储的大文本数据应该压缩后存储

对于大文本写入到Redis时,要压缩后存储。大文本数据存入redis,除了带来极大的内存占用外,在访问量高时,很容易就会将网卡流量占满,进而造成整个服务器上的所有服务不可用,并引发雪崩效应,造成各个系统瘫痪

  1. 线上redis一定不可使用Keys正则匹配操作

  2. 选择合适的数据类型

  • 在不能确定其它复杂数据结构一定优于String类型时,避免使用Redis的复杂数据结构。
  • 每种数据结构都有相应的使用场景,String类型是Redis中最简单的数据类型,建议使用String类型。
  • 但是考虑到具体的业务场景,综合评估性能、存储、网络等方面之后使用适当的数据结构。
  • 需要根据业务场景选择合适的类型,常见的如:String可以用作普通的K-V、简单数据类类型等;Hash可以用作对象如商品、经纪人等,包含较多属性的信息;List可以用作消息队列、医生粉丝/关注列表等;Set可以用于推荐;SortedSet可以用于排行榜等。

扫码关注有惊喜

(转载本站文章请注明作者和出处 白贺-studytime

Post Directory