重磅：Redis 开发手册 | 花果山版（免费下载）

Github: https://github.com/Jackson0714/PassJava-Learning

个人网站也会持续更新：http://www.passjava.cn

强制：代表如果不按照规范的方式做，将会带来很大的问题，比如导致系统性能很差。

参考：代表建议的方式，按照这样的规范去做会比较合适，但是需要依据实际业务来决定是否这样做。

推荐：代表非常推荐的规范，按照这样的方式能够提升性能、节省内存空间，或增加开发和运维的便捷性，可直接应用到实践中。

强制规范

1.【强制】生产环境禁用 KEYS、FLUSHALL、FLUSHDB 命令。

说明：

• 因为 KEYS 需要对 Redis 的全局哈希表进行全表扫描，严重阻塞 Redis 主线程。

• FLUSHALL 会删除实例上的所有数据库，如果数据量很大，会严重阻塞 Redis 主线程。

• FLUSHDB 会删除数据库中的数据，如果数据量很大，会严重阻塞 Redis 主线程。

参考方案

1.【参考】控制 String 类型数据的大小不超过 10 KB，避免 bigkey。

说明：bigkey 不是说 key 很大，而是 value 很大。

2.【参考】给不同业务的数据保存到不同实例。

说明：Redis 默认有 16 个数据库实例，可以将不同业务的数据存放到不同实例，保证业务隔离，读写操作相互不影响。

3.【参考】控制集合类型的元素个数不超过 1 万个，避免集合类型的 bigkey。

4.【参考】使用 Redis 尽量保存热数据，而不是将所有数据都缓存起来，避免缓存空间的浪费。

5.【参考】Redis 实例的容量控制在 2~6 GB。无论是 RDB 快照还是主从集群同步，都可以较快地完成，不会阻塞正常请求的处理。

6.【参考】慢查询日志定期持久化。

说明：慢查询日志可能很大，可以将日志放到数据库，方便查询。

7.【参考】慢查询参数 slowlog-max-len（ 建议调大，线上设置为 1000。

说明：slowlog-max-len：慢查询列表可以存放多少条数据，增大慢查询列表可以减少被剔除的可能。

8.【参考】慢查询参数 slowlog-log-slower-than 按照并发量调整。

说明：slowlog-log-slower-than 默认值超过 10 ms 被判定为慢查询，可以根据高并发场景调整该值。

9.【参考】Redis 可用作消息队列，优点是足够简单。

说明：但发布订阅机制较弱，且不具备堆积和回溯消息的能力。

10.【参考】使用 bgsave 命令生成 RDB 文件，而不是 save 命令。

说明：

RDB 持久化可以手动执行也可以根据配置定期执行，它的作用是将某个时间点上的数据库状态保存到 RDB 文件中，RDB 文件是一个压缩的二进制文件，通过它可以还原某个时刻数据库的状态。由于 RDB 文件是保存在硬盘上的，所以即使 redis 崩溃或者退出，只要 RDB 文件存在，就可以用它来恢复还原数 据库的状态。

可以通过 SAVE 或者 BGSAVE 来生成 RDB 文件。

SAVE 命令会阻塞 redis 进程，直到 RDB 文件生成完毕，在进程阻塞期间，redis 不能处理任何命令请 求，这显然是不合适的。

BGSAVE 则是会 fork 出一个子进程，然后由子进程去负责生成 RDB 文件，父进程还可以继续处理命令请 求，不会阻塞进程。

11.【参考】有条件的情况下部署读写分离架构。

12.【参考】分布式锁推荐使用 Lua 脚本实现。

13.【参考】优先使用先更新数据库再更新缓存。

说明：

• 如果删除缓存失败，可以重试删除。
• 有并发请求时，可能有短暂的不一致。
• 为什么不先删除缓存：先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力。

推荐方案

1.【推荐】使用业务名作为 key 的前缀。

说明：可以很快识别出 key 所属的业务。推荐命名方式：业务名+冒号+数据名。如 mc:act_123456:share_count: 代表会员系统（member center）中，用户分享了多少次活动，活动 id 为 123456。

2.【推荐】控制 key 的长度，推荐使用缩写形式。

说明：当 key 字符串的长度增加时，SDS 中的元数据也会占用更多内存空间。所以为了减少 key 占用的内存空间，尽量减少 key 的长度。比如使用英文首字母缩写。

3.【推荐】使用高效序列化方法和压缩方法。

说明：为了减少 value 的大小，将字符串使用二进制安全的数组来保存，序列化成二进制数据写入到 Redis 中。另外也可以使用压缩工具 snappy 或 gzip 将数据压缩后再写入 Redis。

4.【推荐】能用整数就用整数，充分利用对象共享池。

说明：Redis 内部维护了 0 ~ 9999 一万个整数对象，可作为共享池使用。当满足业务需求的前提下，尽量用整数。

5.【推荐】开启 AOF 每秒刷盘

说明：AOF 有三种机制，选择第二种 Everysec 每秒写回策略，性能较好，保证尽可能少丢失数据。

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

6.【推荐】开启 AOF 和 RDB 持久化

说明：建议 AOF 和 RDB 都开启，双重保护数据避免丢失。Redis 重启时会先读取 AOF 日志文件，进行数据恢复，如果 AOF 日志有损坏，就只能通过 RDB 文件恢复了。

7.【推荐】给数据设置过期时间。

说明：节省缓存的空间，非热数据需要被自动删除然后释放内存空间。例外情况是有些数据需要提前加载到缓存中，比如秒杀商品，这个在业界被称作商品预热。

8.【推荐】谨慎使用 MONITOR 命令。

说明：MONITOR 命令在执行后，会持续输出检测到的各个命令操作，来检查命令的执行情况。但是这些监控内容会不断写到输出缓冲区，如果命令很多，很可能造成缓冲区溢出，对 Redis 性能造成影响。

9.【推荐】谨慎使用全量操作命令。

说明：对于集合类型的数据来说，谨慎使用全量操作，比如 HGETALL、SMEMBERS 这些命令，都会进行全量扫码，如果集合数据很多，可能会阻塞 Redis 主线程。

推荐使用 SSCAN、HSCAN 分配返回数据。另外可以对业务数据进行拆分，比如按照日期、所属区域等拆分。

10.【推荐】部署监控云平台

说明：推荐部署开源的监控平台 CacheCloud。

11.【推荐】尽可能在不同物理机上部署 Redis 所有哨兵节点。

12.【推荐】哨兵节点的个数尽可能大于等于 3 且最好为基数。

说明：因为领导者选择的条件是需要至少一半节点再加一个节点，奇数个节点可以在满足该条件的基础上节省一个节点。

13.【推荐】使用 Bitmaps 用来做独立用户统计，有效节省内存。

14.【推荐】缓存穿透问题推荐使用缓存空对象和布隆过滤器来解决。

15.【推荐】缓存雪崩问题推荐使用客户端降级、提前演练、缓存层实现高可用（如 Redis+本地缓存）、提前做好限流机制、降低缓存同时过期的概率。

16.【推荐】缓存击穿问题推荐使用互斥锁、热点 key 永不过期、定期延长热点 key。

本手册会持续更新，回复 Redis 获取本手册的电子版。

回复 嵩山获取 Java 开发手册嵩山版。