Redis最佳实践 | 滩之南

标签: | 发表时间:2020-06-15 09:24 | 作者:
出处:http://www.hyhblog.cn
图片来自pixabay.com的katja会员

1. 简介

Redis是业界流行的缓存组件,为了规范Redis缓存的使用,避免落入各种问题陷阱,特此编写了此开发规范。本规范结合实际情况,描述了需要遵守的Redis最佳使用规约,及其供参考的最佳实践,供研发团队在项目开发中使用。

本文将出现如下规约术语,其中根据约束力强弱,规约分别有如下三级,
【强制】必须遵守的规约
【推荐】推荐遵守的规约,若无特殊情况,需要遵守该规约
【参考】参考遵守的规约,团队根据实际情况,可以选择性的遵守

每一个规约,根据情况,将有如下附加说明,

  • 说明:对规约进一步的引申和解释
  • 正例:提供一个正面遵守规约的样例
  • 反例:提供一个规约的反面样例,以及真实的错误案例,提醒误区

2. 规约

2.1 键值设计

  1. 【强制】键的命名使用英文小写和冒号、下划线、数字,其中冒号和下划线不能作为键名的开始和结束,而冒号为命名空间分隔符。不要使用中文和特殊字符作为健名。
    • 正例:"pphh:account:user1"
    • 反例1:"pphh.账号-USER1",该反例使用了点、中文、中划线、英文大写。
    • 反例2:":pphh:account:user1_", 该反例使用了冒号和下划线作为开始和结束
  2. 【推荐】键的命名尽量简单、清晰、易懂,长度尽量控制在32个字符以内,不要超过64个字符。
    • 说明:长的键名不仅消耗内存空间,而且会影响键的搜索查询速度。为了保证键的可读性,也不推荐太短的键名,比如"u1000flw",可以使用"user:1000:followers"来表达。
    • 反例1:"pphh:account:loooooooooooooooooooooooooooooooooooooooooog:name"
  3. 【推荐】键的命名空间分为三级,格式为 {系统简称}:{应用名}:{业务健名},命名空间通过冒号区分,公共键值以common表示。
    • 正例1:"web:home_page:click"
    • 正例2:"common:user_login:verification_code"
    • 反例3:"web_home_page_click"
  4. 【推荐】键的值存储空间大小尽量在10KB以内,不推荐存储大于1MB的值。

  5. 【推荐】对于列表键(Hash、List、Set、Zset),尽量控制元素个数不超过千万数量级,若大于这个数量级,建议通过键值切分列表。

  6. 【推荐】建议List当做队列来使用。

2.2 应用规约

  1. 【推荐】业务应用尽量不在Redis存储持久状态,并且需要考虑和实现键值随时失效时的数据更新方法。

  2. 【推荐】对于键值,建议设置随机失效时间,避免同一时间大量键值失效,从而导致的缓存雪崩问题。

    • 说明:设置合适的随机失效时间,以避免在同一时间大量key失效。
  3. 【推荐】在使用缓存时,关注访问不存在键时导致的缓存穿透问题,关注热key导致的缓存击穿问题。
    • 说明:可以通过监控机制获取当前热key的访问情况,以便改进键值分布,详情见下文的监控告警。
  4. 【强制】禁止使用全表搜索命令,比如keys等命令。
    • 说明:请使用scan实现游标式的遍历,建议通过rename-command将keys命令禁用。
  5. 【推荐】使用scan实现游标式的遍历,实现全表搜索。

  6. 【推荐】对于O(N)时间复杂度的Redis命令,在使用时要预估N的大小,建议N不大于1000。

    • 说明:对于O(N)的Redis命令,当N的数量级不可预知时,则应避免使用。对一个Hash数据执行HGETALL/HKEYS/HVALS命令,通常来说这些命令执行的很快,但如果这个Hash中的元素数量级增大后,耗时就会成倍增长。
  7. 【推荐】键的排序、并集、交集等操作时间复杂度都在O(N),建议这些排序、并集、交集操作放在应用代码里执行。
    • 说明:使用SUNION对两个Set执行并集操作,或使用SORT对List/Set执行排序操作等时,当列表元素很多时,容易导致Redis操作时间很长,形成阻塞。
  8. 【强制】禁止如下命令的使用:flushall,flushdb
    • 说明:键值的删除建议通过scan和del命令相配合的方式删除,建议通过rename-command将flushall和flushdb命令禁用。
  9. 【推荐】推荐使用Redis的批量操作命令,比如MSET/MGET/HMSET/HMGET等等,以取代多次单键操作。
    • 说明:一个MSET批量操作命令可以替代多次SET操作,这可以大大减少维护网络连接和传输数据所消耗的资源和时间。

2.3 服务端配置

  1. 【推荐】搭建Redis集群,保障高可用服务,对热键可以考虑读写分离的架构实现。

  2. 【推荐】选择RDB的数据持久化方式。

    • 说明:Redis支持RDB和AOF两种持久化方式,相比AOF,RDB方式性能影响最小,其保存快照时是通过fork的子线程进行,几乎不影响Redis处理客户端请求,生成的快照文件大小也比AOF方式小,从快照中恢复数据的速度也要更快。RDB的缺点是其快照生成是定期的,在Redis出现问题时会出现数据丢失,这需要业务代码能够进行一定的容错处理(即:Redis缓存不保证数据的一致性)。
              save 900 1     # 每900秒检查一次数据变更情况,如果发生了1次或以上的数据变更,则进行RDB快照保存
    save 300 10    # 每300秒检查一次数据变更情况,如果发生了10次或以上的数据变更,则进行RDB快照保存
    save 60 10000  # 每60秒检查一次数据变更情况,如果发生了100次或以上的数据变更,则进行RDB快照保存
  3. 【建议】合理使用Redis database功能
    • 说明:Redis database主要是实现命名空间的功能,实际工作中通过冒号区分命名空间已经足够。Redis的多数据库功能比较简单,不同的数据库支持空间查询、键值清空等操作,并且多个数据库还是单线程处理,相互之间有影响,不同数据库是通过数字区分。
  4. 【推荐】关注网络带宽和延时
    • 说明:相比CPU和内存,网络带宽和延时对Redis服务带来的性能影响更加明显、更加直接。一个4KB的字符串,在10000 q/s的高并发请求量下需要的带宽达312.5 Mbit/s,这个需要千兆带宽的网卡。
  5. 【推荐】设置最大内存,不超过物理内存空间的大小,避免使用swap空间。
    • 说明:默认情况下,在32位OS中,Redis最大使用3GB的内存,在64位OS中则没有限制。当应用使用的虚拟内存空间暂满了物理内存空间,则会开始使用swap空间,可以通过maxmemory来设置Redis的可用最大内存。注意设置时预留一定的主机物理可用内存,以便其它应用运行。
              maxmemory 4000mb
  6. 【推荐】设置数据淘汰策略,当Redis的内存空间达到最大可用内存后,则可以根据有效的淘汰策略尝试淘汰数据,释放空间。
    • 说明:默认情况下,Redis不进行数据淘汰。如果当Redis的内存空间达到设置的maxmemory后,若没有配置数据淘汰策略,或者没有数据可以淘汰,那么Redis会对所有写请求返回错误。推荐使用volatile-lru,使用LRU算法进行数据淘汰(淘汰上次使用时间最早的,且使用次数最少的key),其只淘汰设定了有效期的key。
              maxmemory-policy volatile-lru   # 默认是noeviction,即不进行数据淘汰
  7. 【强制】开启慢查询记录。
              slowlog-log-slower-than 10000  # 执行时间慢于10毫秒的命令计入慢查询日志
    slowlog-max-len 1024  # 慢查询日志记录长度

2.4 客户端配置

  1. 【强制】使用连接池
    • 说明:Redis连接的创建非常耗时,Redis服务的键值查询一般在微妙级别,但是网络连接和传输的耗时在毫秒级别,因此通过连接池来保持连接,可以有效地保证Redis缓存的请求速度,避免频繁连接带来的性能损耗。
  2. 【强制】合理配置连接池
    • 说明:Redis服务端可支持的连接数是有限的,合理配置连接池,可以有效地支持高并发需求场景,也可以在空闲时节约连接数。这些配置包括:最小和最大空闲连接数、空闲连接淘汰策略等。

2.5 安全

  1. 【强制】Redis在设计时要求运行在一个安全的内网,因此禁止暴露Redis服务到外网空间。
    • Redis在设计之初是为了最大的性能考虑,在安全上考虑比较弱,因此不应该暴露Redis服务到外网空间,也就是不应该有外网的客户端访问Redis TCP端口服务。
  2. 【强制】设置用户登录密码

2.6 监控告警

  1. 【强制】定时监控慢查询,对于慢查询操作进行分析并解决,避免再次发生。

  2. 【推荐】定时分析Redis big keys,避免占用空间大的Redis健值,合理拆分。

    • 说明:可以通过redis-cli --bigkeys -i 0.1命令查询大的Redis健值。
  3. 【推荐】定时分析Redis热键,设置合理的过期失效时间和更新时间,设计合理的键值分布。
    • 说明:在Redis 4.0版本以上,可以通过redis-cli --hotkeys命令查询大的Redis热键。
  4. 【推荐】定时分析Redis内存空间使用情况,通过RDB快照获取内存空间,查出占用空间大的键值,并进行拆分修复。

3. 参考资料

  1. Redis官方文档
  2. Redis官网:数据类型简介
  3. Redis官网:性能简介
  4. Redis官网:安全简介
  5. 阿里云Redis开发规范
  6. Redis基础、高级特性与性能调优
  7. 阿里云Redis最佳实践:内存分析方法
  8. 阿里云Redis最佳实践:Redis 4.0 热点Key查询方法

相关 [redis 最佳实践] 推荐:

Redis最佳实践 | kikoroc

- -
redis是一款开源的内存数据存储系统,可以用作数据库、缓存甚至是消息中间件(pub/sub)来使用. 与memcache相比,redis支持更多的数据结构,比如string,hash,list,set,bit map,sorted set甚至是geo等等,基本覆盖了日常开发中使用到的数据结构. 而且redis十分高效,当然是建立在合理使用的前提下.

Redis最佳实践 - 简书

- -
redis是一款开源的内存数据存储系统,可以用作数据库、缓存甚至是消息中间件(pub/sub)来使用. 与memcache相比,redis支持更多的数据结构,比如string,hash,list,set,bit map,sorted set甚至是geo等等,基本覆盖了日常开发中使用到的数据结构. 而且redis十分高效,当然是建立在合理使用的前提下.

Redis最佳实践 | 滩之南

- -
图片来自pixabay.com的katja会员. Redis是业界流行的缓存组件,为了规范Redis缓存的使用,避免落入各种问题陷阱,特此编写了此开发规范. 本规范结合实际情况,描述了需要遵守的Redis最佳使用规约,及其供参考的最佳实践,供研发团队在项目开发中使用. 本文将出现如下规约术语,其中根据约束力强弱,规约分别有如下三级,.

Redis 高可用架构最佳实践 | 温国兵的随想录

- -
0x02 Sentinel 原理. 0x03 Redis 高可用架构. 3.1 Redis Sentinel 集群 + 内网 DNS + 自定义脚本. 3.2 Redis Sentinel 集群 + VIP + 自定义脚本. 3.3 封装客户端直连 Redis Sentinel 端口. 3.4 Redis Sentinel 集群 + Keepalived/Haproxy.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.

MongoDB最佳实践

- - NoSQLFan
将 MongoDB加入到我们的服务支持列表中,是整个团队年初工作计划中的首要任务. 但我们感觉如果先添加一项对NoSQL存储的支持,而不是先升级已支持的关系型数据库,可能对用户不太好,毕竟目前的用户都使用关系型数据库. 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做.

Dockerfile 最佳实践

- - DockOne.io
在容器领域,Docker 公司提出的容器镜像已经成为目前容器打包交付的事实标准. 构建镜像需要编写 Dockerfile,如何编写一个优雅的 Dockerfile 呢. 在 Docker 公司的官方文档中给出了一篇:《 Best practices for writing Dockerfiles》.

文章: Grails最佳实践

- - InfoQ cn
我在IntelliGrape工作,这是一家专门使用Groovy & Grails进行开发的公司. 本文是我们Grails项目遵循的最佳实践的基本清单,收集自邮件列表、Stack Overflow、博文, 播客和 IntelliGrape的内部讨论. 它们分为控制器、服务、Domain、视图、TagLib、测试和其他.

PHP最佳实践(译)

- - CSDN博客Web前端推荐文章
原文:  PHP Best Practices-A short, practical guide for common and confusing PHP tasks. 译者: youngsterxyf. 本文档最后审阅于2013年3月8日. 由我, Alex Cabal,维护该文档. 我编写PHP程序已有很长一段时间了,当前我 经营着 Scribophile,由认真作家组成的一个在线写作团体,  Writerfolio,为自由职业者提供的一个易用写作工具集,以及  Standard Ebooks,一个图文并茂、无数字版权管理的公共领域电子书出版商.