「黑马 Redis」二、最佳实践

多级缓存跳过

键值设计

优雅的 key 结构

Redis 的 Key 虽然可以自定义，但最好遵循下面的几个最佳实践约定：

遵循基本格式：［业务名称］：［数据名］：［id］

长度不超过 44 字节

不包含特殊字符

例如：我们的登录业务，保存用户信息，其 key 是这样的： login:user:10

优点：

可读性强

避免 key 冲突

方便管理

更节省内存：key 是 string 类型，底层编码包含 int、embstr 和 raw 三种。embstr 在小于 44 字节使用，采用连续内存空间，内存占用更小

set num 123 如果 type num 得到 string 但是 object encoding num 得到底层是 int
set name Jack 如果 type name 得到 string 但是 object encoding name 得到底层是 embstr

BigKey

什么是 bigkey

Key 本身数据量大

成员数量过多

成员数据量大

推荐值

单个 key 的 value 小于 10KB

对于集合类型的 key，建议元素数量小于 1000

危害：

网络阻塞

数据倾斜，分片不均衡

Redis 阻塞

序列化与反序列化 CPU 压力大

恰当的数据结构

对于一个 User 对象存储

String 类型的字符串整体存储 user:1

打散字段，String 类型分别存储 user:1 user:1

Hash 结构

Hash 结构不超过 1000 Entry，可以拆分

批处理

大数据导入

1 个命令响应 = 1 次网络往返 + 1 次执行

所以一次传递而非多次传递同等数据量更好，注意不要太多，不然会阻塞网络

pipeline 放入命令到管道，支持原生的各种命令，只是一次发送这些全部的命令到 Redis，而非原生的 MSET 的原子性大量操作

持久化配置

Redis 的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：

用来做缓存的 Redis 实例尽量不要开启持久化功能

建议关闭 RDB 持久化功能，使用 AOF 持久化

利用脚本定期在 slave 节点做 RDB，实现数据备份

设置合理的 rewrite 阈值，避免频繁的 bgrewrite

配置 no-appendfsync-on-rewrite = yes，禁止在 rewrite 期间做 AOF，避免因 AOF 引起的阻塞

部署有关建议：

Redis 实例的物理机要预留足够内存，应对 fork 和 rewrite

单个 Redis 实例内存上限不要太大，例如 4G 或 8G。可以加快 fork 的速度、减少主从同步、数据迁移压力

不要与 CPU 密集型应用部署在一起

不要与高硬盘负载应用一起部署。例如：数据库、消息队列

慢查询

在 Redis 中执行耗时超过某个阈值的命令，称为慢查询（不止查询），Redis 单线程所以慢查询会阻塞

慢查询的阈值可以通过配置指定：

slowlog-log-slower-than: 慢查询阈值，单位是微秒。默认是 10000，建议 1000

慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：

slowlog-max-len: 慢查询日志（本质是一个队列）的长度。默认是 128，建议 1000

查看慢查询日志列表：

slowlog len: 查询慢查询日志长度

slowlog get [n]: 读取 [n]/ 全部 条慢查询日志

slowlog reset: 清空慢查询列表

此文由 Mix Space 同步更新至 xLog
原始链接为 https://blog.0xling.cyou/posts/redis/redis-2