Redis-实践知识

转自极客时间Redis 亚风 原文视频：https://u.geekbang.org/lesson/535?article=681062

Redis最佳实践

普通KEY

Redis 的key虽然可以自定义，但是最好遵循下面几个实践的约定：
格式：[业务名称]:[数据名]:[id] 长度不超过44字节 不包含特殊字符
例如： login:user:10
这样做的好处是
? 可读性强
? 避免key冲突
? ?便管理
? 节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在?于44字节使?，采?连续内存空间，内存占?更?。

set key "123"
object encoding key

BigKey

什么是bigKey?

• BigKey通常以Key的??和Key中成员的数量来综合判定，例如：
• Key本身的数据量过?：?个String类型的Key，它的值为5 MB（key + val 加在一起 也就是一个Entry）。
• Key中的成员数过多：?个ZSET类型的Key，它的成员数量为10,000个。
  Key中成员的数据量过?：?个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总??为100 MB。
  推荐值：
  单个key的value?于10KB。
  对于集合类型的key，建议元素数量?于1000。
  BigKey的问题
  ? ?络阻塞
  对Bigkey执?读请求时，少量的QPS就可能导致带宽使?率被占满，导致Redis实例，乃?所在物理机变慢
  ? 数据倾斜
  BigKey所在的Redis实例内存使?率远超其他实例，?法使数据分?的內存资源达到均衡
  ? Redis阻塞
  对元素较多的hash、 list、 zset等做运算会耗时较久，使主线程被阻塞
  ? CPU压?
  对BigKey的数据序列化和反序列化会导致CPU的使?率飙升，影响Redis实例和本机其它应?

BigKey的发现
? redis-cli --bigkeys
利? redis-cli提供的–bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key

redis-cli --bigkeys #扫描bigkeys

这里只得出了最大的key是54bytes,没有统计有那些key占用了多少空间，实际用用价值不大。

memory usage key #使用内存大小 (integer) 112
strlen key #也是使用内存大小
llen list #求内存大小
#最好是使用后面两个命令来求  memory usage性能不好

? scan扫描
??编程，利?scan扫描Redis中的所有key，利?strlen、hlen等命令判断key的?度（此处不建议使?MEMORY USAGE)

scan 0 #第一页是0
#第二页则是 返回什么值 往下翻页就是转这个值
scan 7

// 自己编程
final static int STR_MAX_LEN = 10 * 1024;
final static int HASH_MAX_LEN = 1000;
 @Test
 void testScan() {
     int maxLen = 0;
     long len = 0;
     String cursor = "0";
     do {
         // 扫描并获取?部分key
         ScanResult<String> result = jedis.scan(cursor);
         // 记录cursor
         cursor = result.getCursor();
         List<String> list = result.getResult();
         if (list == null || list.isEmpty()) {
             break;
         }
         // 遍历
         for (String key : list) {
             // 判断key的类型
             String type = jedis.type(key);
             switch (type) {
                 case "string":
                     len = jedis.strlen(key);
                     maxLen = STR_MAX_LEN;
                     break;
                 case "hash":
                     len = jedis.hlen(key);
                     maxLen = HASH_MAX_LEN;
                     break;
                 case "list":
                     len = jedis.llen(key);
                     maxLen = HASH_MAX_LEN;
                     break;
                 case "set":
                     len = jedis.scard(key);
                     maxLen = HASH_MAX_LEN;
                     break;
                 case "zset":
                     len = jedis.zcard(key);
                     maxLen = HASH_MAX_LEN;
                     break;
                 default:
                     break;
             }
             if (len >= maxLen) {
                 System.out.printf("Found big key : %s, ty
pe: %s, length or size: %d %n", key, type, len);
             }
         }
     } while (!cursor.equals("0"));
 }

? 第三??具
利?第三??具，如 Redis-Rdb-Tools 分析RDB快照?件，全?分析内存使?情况（推荐使用，但是实时性比较差）
? ?络监控
?定义?具，监控进出Redis的?络数据，超出预警值时主动告警。直接监控网络数据包。

如何删除BigKey
BigKey内存占?较多，即便时删除这样的key也需要耗费很?时间，导致
Redis主线程阻塞，引发?系列问题。
? redis 3.0 及以下版本
如果是集合类型，则遍历BigKey的元素，先逐个删除?元素，最后删除Bigkey
? Redis 4.0以后
Redis在4.0后提供了异步删除的命令：unlink

怎么存储key
例1：?如存储?个User对象，我们有三种存储?式：
?式?：json字符串

user:1 {"name":"jack","age":21}

优点：
简单粗暴
缺点：
数据耦合，不够灵活
方式二
字段打散

user:1:name jack
user:1:age 21

优点：可以灵活访问对象任意字段
缺点：占?空间?、没办法做统?控制
方式三

hset uid name zhonglimo #单字段赋值
hmset uid name zhonglimo age 24 #多字段赋值

优点：底层使?ziplist，空间占??，可以灵活访问对象的任意字段
缺点：代码相对复杂
实战案例

假如有hash类型的key，其中有100万对field和value，field是?增id，这个key存在什么问题？如何优化？

存在的问题：
? hash的entry数量超过500时，会使?dict?不是ZipList，内存占?较多
? 可以通过hash-max-ziplist-entries配置entry上限。但是如果entry过多就会
导致BigKey问题
解决方案一直接将hash进行拆分成String：

存在的问题：
? string结构底层没有太多内存优化，内存占?较多
? 想要批量获取这些数据?较麻烦

方式二：拆分为?的hash，将 id / 100 作为key，将id % 100 作为field，这样每100个元素为?个Hash

HotKey

比如我有一个redis集群，由于2有一个热键，所有的请都打到了这个机器上有可能这个机器扛不住压力会挂掉，服务因而无法使用。

如果是读：
比如用哈希取模的方法进行路由到不同的机器，但是键也要做同样的拆分因为一个集群不能相同的键。

如果是写，比如秒杀扣库存，每台机器存放100个库存：

但是如果消耗到最后可能有碎片，比如剩了5个这个时候可以通过限流排队取消耗这些碎片。还有一种解决方案是消耗到剩一些碎片的时候，直接关闭流量，保证不超消费就行。

Pipeline批处理

MSET（不能被打断）虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使?Pipeline功能：

void testPipeline() {
	Pipline pipeline = jedis.pipelined();
	for (int i = 1; i <= 10000; i ++) {
		if (i % 1000 == 0） {
			pipline.sync();
		}
	}
}

注意事项：
? 批处理时不建议?次携带太多命令
? Pipeline的多个命令之间不具备原?性

MSET/Pipeline这样的批处理需要在?次请求中携带多条命令，?此时如果Redis是?个集群，那批处理命令的多个key必须落在?个插槽中，否则就会导致执?失败。
解决方案：

并行Slot在spring中的应用Spring->lettuce or Jedis->MultiKeyCommands

@Override
public RedisFuture<String> mset(Map<K,V> map) {
	Map<Integer, List<K>> partitioned = SlotHash.partition(codec, map.keySet());
	if (partitioned.size() < 2) {
		return super.mset(map);
	}
}

hash_tag

mset {a}name  zhangsan {a}age 12 {a}set male #这个hash Tag可以将key路由到同一个槽中

但是hash_tag 存在数据倾斜的问题，实战中推荐使用并行slot.

RDB 数据文件备份

RDB全称Redis Database Backup file (Redis数据备份?件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照?件，恢复数据。快照?件称为RDB?件，默认是保存在当前运??录。

#有两种命令
save #由redis主进程来执行RDB,会阻塞所有命令
#fork 出?个?进程，?进程执?，不会阻塞 Redis 主线程，默认选项
bgsave #开启子进程执行RDB，避免主进程受到影响

Redis 可以通过创建快照来获得存储在内存??的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进?备份，可以将快照复制到其他服务器从?创建具有相同数据的服务器副本（Redis 主从结构，主要?来提?Redis 性能），还可以将快照留在原地以便重启服务器的时候使?。快照持久化是 Redis 默认采?的持久化?式，在 redis.conf 配置?件中默认有此下配置：

#这些配置是一个或的关系，可以多个都生效，底层执行的都是bgsave 会自动转换为bgsave
save 900 1 #900秒以后如果有一个key变化触发bgsave
save 300 10 #300秒以后如果有10个key变化可以出发bgsave
save 60 10000 #一分钟如果有10000个key发生变化触发bgsave
rdbcompression yes #是否开启压缩，建议不开启，压缩会消耗cpu
dbfilename dump.rdb #rdb文件名称
dir ./ #文件保存目录

bgsave开始时会fork主进程得到?进程，?进程共享主进程的内存数据。完成fork后读取内存数据并写RDB ?件。fork采?的是copy-on-write技术：当主进程执?读操作时，访问共享内存；当主进程执?写操作时，则会拷??份数据，执?写操作。

AOF 追加文件

AOF全称为Append Only File（追加?件）。Redis处理的每?个写命令都会记录在AOF?件，可以看做是命令?志?件。
与快照持久化相?，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF?式的持久（Redis6.0 之后已经默认是开启了），可以通过 appendonly 参数开启：appendonly yes

开启 AOF 持久化后每执??条会更改 Redis 中的数据的命令，Redis 就会将该命令写?到 AOF 缓冲区（用户空间） server.aof_buf 中，然后再写?到 AOF ?件中（此时在内核缓存区），最后再根据持久化?式（ fsync策略）的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了，否则依然存在数据丢失的?险，?如说：系统内核缓存区的数据还未同步，磁盘机器就宕机了，那这部分数据就算丢失了。

AOF ?件的保存位置和 RDB ?件的位置相同，都是通过 dir 参数设置的，默认的?件名appendonly.aof。

AOF 持久化功能的实现分为 5 步：
1 命令追加（append） ：所有的写命令会追加到 AOF 缓冲区中。
2 ?件写?（write） ：将 AOF 缓冲区的数据写?到 AOF ?件中。这?步
需要调?write函数（系统调?），write将数据写?到了系统内核缓冲区之
后直接返回了（延迟写）。注意！此时并没有同步到磁盘。
3 ?件同步（fsync） ：AOF 缓冲区根据对应的持久化?式（ fsync 策略）
向硬盘做同步操作。这?步需要调? fsync 函数（系统调?）， fsync 针
对单个?件操作，对其进?强制硬盘同步，fsync 将阻塞直到写?磁盘完
成后返回，保证了数据持久化。
4 ?件重写（rewrite） ：随着 AOF ?件越来越?，需要定期对 AOF ?件
进?重写，达到压缩的?的。
5 重启加载（load） ：Redis 重启时，可以加载 AOF ?件进?数据恢复。

Linux 系统直接提供了?些函数?于对?件和设备进?访问和控制，这些函数被称为系统调?（syscall）。

write ：写?系统内核缓冲区之后直接返回（仅仅是写到缓冲区），不会?即同步到硬盘。虽然提?了效率，但也带来了数据丢失的?险。同步硬盘操作通常依赖于系统调度机制，Linux 内核通常为 30s 同步?次，具体值取决于写出的数据量和 I/O 缓冲区的状态。
fsync ： fsync?于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。

Redis fsync策略
在 Redis 的配置?件中存在三种不同的 AOF 持久化?式（ fsync策略），它们分别是：
? appendfsync always：主线程调? write 执?写操作后，后台线程（ aof_fsync 线程）?即会调? fsync 函数同步 AOF ?件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能

? appendfsync everysec ：主线程调? write 执?写操作后?即返回，由后台线程（ aof_fsync 线程）每秒钟调? fsync 函数（系统调?）同步?次 AOF ?件

? appendfsync no ：主线程调? write 执?写操作后?即返回，让操作系统决定何时进?同步，Linux 下?般为 30 秒?次为了兼顾数据和写?性能，可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步?次 AOF ?件，Redis 性能收到的影响较?。?且这样即使出现系统崩溃，?户最多只会丢失?秒之内产?的数据。当硬盘忙于执?写?操作的时候，Redis 还会优雅的放慢??的速度以便适应硬盘的最?写?度。
**Multi Part AOF **
从 Redis 7 开始，Redis 使?了 Multi Part AOF 机制。顾名思义，Multi Part AOF 就是将原来的单个 AOF ?件拆分成多个 AOF ?件。在 Multi Part AOF 中，AOF ?件被分为三种类型，分别为：
BASE：表示基础 AOF ?件，它?般由?进程通过重写产?，该?件最多只有?个。
INCR：表示增量 AOF ?件，它?般会在 AOFRW 开始执?时被创建，该?件可能存在多个。
HISTORY：表示历史 AOF ?件，它由 BASE 和 INCR AOF 变化?来，每次 AOFRW 成功完成时，本次 AOFRW 之前对应的 BASE 和 INCR AOF 都将变为 HISTORY，HISTORY 类型的 AOF 会被 Redis ?动删除。
当 AOF 变得太?时，Redis 能够在后台?动重写 AOF 产??个新的 AOF ?件，这个新的 AOF ?件和原有的 AOF ?件所保存的数据库状态?样，但体积更?。

AOF重写

AOF 重写是?个有歧义的名字，该功能是通过读取数据库中的键值对来实现的（扫描键值对重新写一个新文件，不会对之前的AOF进行读写），程序?须对现有 AOF ?件进?任何读?或写?操作。

由于 AOF 重写会进??量的写?操作，为了避免对 Redis 正常处理命令请求造成影响，Redis 将 AOF 重写程序放到?进程?执?。
AOF ?件重写期间，Redis 还会维护?个 AOF 重写缓冲区，该缓冲区会在?进程创建新 AOF ?件期间，记录服务器执?的所有写命令。当?进程完成创建新 AOF ?件的?作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF ?件的末尾，使得新的 AOF ?件保存的数据库状态与现有的数据库状态?致。最后，服务器?新的 AOF ?件替换旧的 AOF ?件，以此来完成 AOF ?件重写操作。

开启 AOF 重写功能，可以调? BGREWRITEAOF 命令?动执?，也可以设置下?两个配置项，让程序?动决定触发时机：

#增长超过多少百分比触发重写
auto-aof-rewrite-percentage 100
#体积多大触发重写
auto-aof-rewrite-min-size 64mb

Redis 7.0 版本之前，如果在重写期间有写?命令，AOF 可能会使??量内存，重写期间到达的所有写?命令都会写?磁盘两次。AOF 重写期间的增量数据如何处理?直是个问题，在过去写期间的增量数据需
要在内存中保留，写结束后再把这部分增量数据写?新的 AOF ?件中以保证数据完整性。可以看出来 AOF 写会额外消耗内存和磁盘 IO，这也是 Redis AOF 写的痛点，虽然之前也进?过多次改进但是资源消耗的本质问题?直没有解决。
阿? Redis 在最初也遇到了这个问题，在内部经过多次迭代开发，实现了 Multi-part AOF 机制来解决，同时也贡献给了社区并随此次 7.0 发布。具体?法是采? base（全量数据）+incr（增量数据）独??件存储的?式。由于 RDB 和 AOF 各有优势，Redis 4.0 开始?持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF ?件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF ??的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

RDB与AOF的对比

RDB ? AOF 优秀的地? ：
RDB ?件存储的内容是经过压缩的?进制数据， 保存着某个时间点的数据集，?件很?，适合做数据的备份，灾难恢复。AOF ?件存储的是每?次写命令，类似于 MySQL 的 binlog ?志，通常会必 RDB ?件?很多。当 AOF 变得太?时，Redis 能够在后台?动重写 AOF。新的 AOF ?件和原有的 AOF ?件所保存的数据库状态?样，但体积更?。不过， Redis 7 之前，如果在重写期间有写?命令，AOF 可能会使??量内存，重写期间到达的所有写?命令都会写?磁盘两次。使? RDB ?件恢复数据，直接解析还原数据即可，不需要?条?条地执?命令，速度?常快。? AOF 则需要依次执?每个写命令，速度?常慢。也就是
说，与 AOF 相?，恢复?数据集的时候，RDB 速度更快。

AOF ? RDB 优秀的地? ：
RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。?成 RDB ?件的过程是?较繁重的， 虽然 BGSAVE ?进程写? RDB ?件的?作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产?影响，严重的情况下甚?会直接把 Redis 服务?宕机。AOF ?持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF ?件，操作轻量。
RDB ?件是以特定的?进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在?版本的 Redis 服务不兼容新版本的 RDB 格式的问题。AOF 以?种易于理解和解析的格式包含所有操作的?志。你可以轻松地导出 AOF ?件进?分析。?如，如果执?FLUSHALL命令意外地刷新了所有内容后，删除最新命令并重启即可恢复之前的状态。持久化可以保证数据安全，但会带来额外的开销，请遵循下列建议：
? ?来做缓存的Redis实例尽量不要开启持久化功能
? 建议关闭RDB持久化功能，使?AOF持久化
? 利?脚本定期在slave节点做RDB，实现数据备份
? 设置合理的rewrite阈值，避免频繁的bgrewrite
? 配置no-appendfsync-on-rewrite =yes，禁?在rewrite期间做aof，避免因
AOF引起的阻塞

部署建议

? Redis实例的物理机要预留?够内存，应对fork和rewrite
? 单个Redis实例内存上限不要太?，例如8G。可以加快fork的速度（fork是到页如果句柄太大，fork也会很慢）、减少主从同步、数据迁移压?
? 不要与CPU密集型应?部署在?起
? 不要与?硬盘负载应??起部署。例如：数据库、消息队列

慢查询

慢查询阈值可以通过配置指定：slowlog-log-slower-than：慢查询阈值，单位是微秒。默认是10000（10ms），建议1000（1ms）
慢查询会被放?慢查询?志中，?志的?度有上限，可以通过配置指定：slowlog-max-len：慢查询?志（本质是?个队列）的?度。默认是128，建议1000
? slowlog len：查询慢查询?志?度
? slowlog get n：读取n条慢查询?志
? slowlog reset：清空慢查询列表、

Redis 安全设置

Redis会绑定在0.0.0.0:6379，这样将会将Redis服务暴露到公?上，?Redis如果没有做身份认证，会出现严重的安全漏洞.
漏洞出现的核?的原因有以下3点：
? Redis未设置密码
? 利?了Redis的config set命令动态修改Redis配置
? 使?了Root账号权限启动Redis

为了避免漏洞，这?给出?些建议：
? Redis?定要设置密码
? 禁?线上使?下?命令：keys、 flushall、 flushdb、 config set等命令。可以利?rename-command禁?。

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 #把修改配置的命令重新命名
rename-command KEYS ""      #必禁命令，线上用这种查询方式绝对是不对的
rename-command FLUSHALL ""  #必禁命令，谁会清除数据呢
rename-command FLUSHDB ""   #必禁命令，谁会清除数据呢
rename-command CONFIG ""    #可以考虑重命名下

? bind：限制?卡，禁?外??卡访问
? 开启防?墙
? 不要使?Root账户启动Redis
? 尽量不是有默认的端?

Redis内存优化

当Redis内存不?时，可能导致Key频繁被删除、响应时间变?、QPS不稳定等问题。当内存使?率达到90％以上时就需要我们警惕，并快速定位到内存占?的原因。

redis info 详解

内存占用

内存缓冲区常?的有三种：
复制缓冲区：主从复制的repl-backlog_buf，如果太?可能导致频繁的全量复制，影响性能。通过repl-backlog-size来设置，默认1mb。
AOF缓冲区：AOF刷盘之前的缓存区域，AOF执?rewrite的缓冲区。?法设置容量上限。
客户端缓冲区：分为输?缓冲区和输出缓冲区，输?缓冲区最?1G且不能设置，输出缓冲区可以设置。
通过下面这个命令进行设置：
class 是一个什么，集群的时候配replica

CLIENT LIST #可以通过Client List 定位问题客户端

Redis集群优化

在Redis的默认配置中，如果发现任意?个插槽不可?，则整个集群都会停?对外服务：

cluster-require-full-coverage  yes #通过这个配置来进行设置 no 是有个一个插槽不可以也可以使用

集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息?少包括：
? 插槽信息
? 集群状态信息
? 集群中节点越多，集群状态信息数据量也越?，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会?常?。
解决途径：
? 避免?集群，集群节点数不要太多，最好少于1000，如果业务庞?，则建?多个集群
? 避免在单个物理机中运?太多Redis实例
? 配置合适的cluster-node-timeout值