1. 简介
Redis是业界流行的缓存组件，为了规范Redis缓存的使用，避免落入各种问题陷阱，特此编写了此开发规范。本规范结合实际情况，描述了需要遵守的Redis最佳使用规约，及其供参考的最佳实践，供研发团队在项目开发中使用。
本文将出现如下规约术语，其中根据约束力强弱，规约分别有如下三级，
【强制】必须遵守的规约
【推荐】推荐遵守的规约，若无特殊情况，需要遵守该规约
【参考】参考遵守的规约，团队根据实际情况，可以选择性的遵守
每一个规约，根据情况，将有如下附加说明，
- 说明：对规约进一步的引申和解释
- 正例：提供一个正面遵守规约的样例
- 反例：提供一个规约的反面样例，以及真实的错误案例，提醒误区
2. 规约
2.1 键值设计
- 【强制】键的命名使用英文小写和冒号、下划线、数字，其中冒号和下划线不能作为键名的开始和结束，而冒号为命名空间分隔符。不要使用中文和特殊字符作为健名。
- 正例："pphh:account:user1"
- 反例1："pphh.账号-USER1"，该反例使用了点、中文、中划线、英文大写。
- 反例2：":pphh:account:user1_"， 该反例使用了冒号和下划线作为开始和结束
- 【推荐】键的命名尽量简单、清晰、易懂，长度尽量控制在32个字符以内，不要超过64个字符。
- 说明：长的键名不仅消耗内存空间，而且会影响键的搜索查询速度。为了保证键的可读性，也不推荐太短的键名，比如"u1000flw"，可以使用"user:1000:followers"来表达。
- 反例1："pphh:account:loooooooooooooooooooooooooooooooooooooooooog:name"
- 【推荐】键的命名空间分为三级，格式为 {系统简称}:{应用名}:{业务健名}，命名空间通过冒号区分，公共键值以common表示。
- 正例1："web:home_page:click"
- 正例2："common:user_login:verification_code"
- 反例3："web_home_page_click"
- 【推荐】键的值存储空间大小尽量在10KB以内，不推荐存储大于1MB的值。
-
【推荐】对于列表键（Hash、List、Set、Zset），尽量控制元素个数不超过千万数量级，若大于这个数量级，建议通过键值切分列表。
-
【推荐】建议List当做队列来使用。
2.2 应用规约
-
【推荐】业务应用尽量不在Redis存储持久状态，并且需要考虑和实现键值随时失效时的数据更新方法。
-
【推荐】对于键值，建议设置随机失效时间，避免同一时间大量键值失效，从而导致的缓存雪崩问题。
- 说明：设置合适的随机失效时间，以避免在同一时间大量key失效。
- 【推荐】在使用缓存时，关注访问不存在键时导致的缓存穿透问题，关注热key导致的缓存击穿问题。
- 说明：可以通过监控机制获取当前热key的访问情况，以便改进键值分布，详情见下文的监控告警。
- 【强制】禁止使用全表搜索命令，比如keys等命令。
- 说明：请使用scan实现游标式的遍历，建议通过rename-command将keys命令禁用。
- 【推荐】使用scan实现游标式的遍历，实现全表搜索。
-
【推荐】对于O(N)时间复杂度的Redis命令，在使用时要预估N的大小，建议N不大于1000。
- 说明：对于O(N)的Redis命令，当N的数量级不可预知时，则应避免使用。对一个Hash数据执行HGETALL/HKEYS/HVALS命令，通常来说这些命令执行的很快，但如果这个Hash中的元素数量级增大后，耗时就会成倍增长。
- 【推荐】键的排序、并集、交集等操作时间复杂度都在O(N)，建议这些排序、并集、交集操作放在应用代码里执行。
- 说明：使用SUNION对两个Set执行并集操作，或使用SORT对List/Set执行排序操作等时，当列表元素很多时，容易导致Redis操作时间很长，形成阻塞。
- 【强制】禁止如下命令的使用：flushall，flushdb
- 说明：键值的删除建议通过scan和del命令相配合的方式删除，建议通过rename-command将flushall和flushdb命令禁用。
- 【推荐】推荐使用Redis的批量操作命令，比如MSET/MGET/HMSET/HMGET等等，以取代多次单键操作。
- 说明：一个MSET批量操作命令可以替代多次SET操作，这可以大大减少维护网络连接和传输数据所消耗的资源和时间。
2.3 服务端配置
- 【推荐】搭建Redis集群，保障高可用服务，对热键可以考虑读写分离的架构实现。
-
【推荐】选择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快照保存 - 【建议】合理使用Redis database功能
- 说明：Redis database主要是实现命名空间的功能，实际工作中通过冒号区分命名空间已经足够。Redis的多数据库功能比较简单，不同的数据库支持空间查询、键值清空等操作，并且多个数据库还是单线程处理，相互之间有影响，不同数据库是通过数字区分。
- 【推荐】关注网络带宽和延时
- 说明：相比CPU和内存，网络带宽和延时对Redis服务带来的性能影响更加明显、更加直接。一个4KB的字符串，在10000 q/s的高并发请求量下需要的带宽达312.5 Mbit/s，这个需要千兆带宽的网卡。
- 【推荐】设置最大内存，不超过物理内存空间的大小，避免使用swap空间。
- 说明：默认情况下，在32位OS中，Redis最大使用3GB的内存，在64位OS中则没有限制。当应用使用的虚拟内存空间暂满了物理内存空间，则会开始使用swap空间，可以通过maxmemory来设置Redis的可用最大内存。注意设置时预留一定的主机物理可用内存，以便其它应用运行。
maxmemory 4000mb - 【推荐】设置数据淘汰策略，当Redis的内存空间达到最大可用内存后，则可以根据有效的淘汰策略尝试淘汰数据，释放空间。
- 说明：默认情况下，Redis不进行数据淘汰。如果当Redis的内存空间达到设置的maxmemory后，若没有配置数据淘汰策略，或者没有数据可以淘汰，那么Redis会对所有写请求返回错误。推荐使用volatile-lru，使用LRU算法进行数据淘汰（淘汰上次使用时间最早的，且使用次数最少的key），其只淘汰设定了有效期的key。
maxmemory-policy volatile-lru # 默认是noeviction，即不进行数据淘汰 - 【强制】开启慢查询记录。
slowlog-log-slower-than 10000 # 执行时间慢于10毫秒的命令计入慢查询日志 slowlog-max-len 1024 # 慢查询日志记录长度
2.4 客户端配置
- 【强制】使用连接池
- 说明：Redis连接的创建非常耗时，Redis服务的键值查询一般在微妙级别，但是网络连接和传输的耗时在毫秒级别，因此通过连接池来保持连接，可以有效地保证Redis缓存的请求速度，避免频繁连接带来的性能损耗。
- 【强制】合理配置连接池
- 说明：Redis服务端可支持的连接数是有限的，合理配置连接池，可以有效地支持高并发需求场景，也可以在空闲时节约连接数。这些配置包括：最小和最大空闲连接数、空闲连接淘汰策略等。
2.5 安全
- 【强制】Redis在设计时要求运行在一个安全的内网，因此禁止暴露Redis服务到外网空间。
- Redis在设计之初是为了最大的性能考虑，在安全上考虑比较弱，因此不应该暴露Redis服务到外网空间，也就是不应该有外网的客户端访问Redis TCP端口服务。
- 【强制】设置用户登录密码
2.6 监控告警
-
【强制】定时监控慢查询，对于慢查询操作进行分析并解决，避免再次发生。
-
【推荐】定时分析Redis big keys，避免占用空间大的Redis健值，合理拆分。
- 说明：可以通过redis-cli --bigkeys -i 0.1命令查询大的Redis健值。
- 【推荐】定时分析Redis热键，设置合理的过期失效时间和更新时间，设计合理的键值分布。
- 说明：在Redis 4.0版本以上，可以通过redis-cli --hotkeys命令查询大的Redis热键。
-
【推荐】定时分析Redis内存空间使用情况，通过RDB快照获取内存空间，查出占用空间大的键值，并进行拆分修复。
