【Redis】BigKey问题

文章目录

- MoreKey案例
- - 大批量往redis里面插入100W测试数据key(管道)
  - 生产上限制keys*/flushdb/flushall等危险命令以防止误删误用
  - scan命令代替了`keys *`,避免了查询卡顿
- BigKey案例
- - 多大算大key
  - 危害
  - 如何产生
  - 如何发现 `redis-cli --bigkeys`、`memory usage`
  - 如何删除->渐进式删除
- BigKey生产调优
- 面试题

MoreKey案例

大批量往redis里面插入100W测试数据key(管道)

生成管道文件命令

for((i=1;i<=100*10000;i++)); do echo "set k$i v$i" >> /tmp/redisTest.txt ;done;
–pipe命令批量插入

cat /tmp/redisTest.txt | /opt/redis-7.0.0/src/redis-cli -h 127.0.0.1 -p 6379 -a 111111 --pipe

生产上限制keys*/flushdb/flushall等危险命令以防止误删误用

通过配置设置禁用这些命令，redis.conf在SECURITY这一项中

scan命令代替了`keys *`,避免了查询卡顿

官网

SCAN命令官网：https://redis.com.cn/commands/scan.html
定义
类似于MSSQL的limit
- 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
- 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
- 不保证每次执行都返回某个给定数量的元素，支持模糊查询
- 一次返回的数量不可控，只能是大概率符合count参数
语法

SCAN cursor [MATCH pattern] [COUNT count]
- cursor -> 游标。
- pattern -> 匹配的模式。
- count -> 指定从数据集里返回多少元素，默认值为10。
返回

SCAN 返回一个包含两个元素的数组，
- 第一个元素是用于进行下一次迭代的新游标
- 第二个元素则是一个数组，这个数组中包含了所有被迭代的元素。如果新游标返回零表示迭代已结束。
SCAN的遍历顺序

非常特别，它不是从第一维数组的第零位一直遍历到末尾，而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏。

使用

redis 127.0.0.1:6379> scan 0
1) "17"
2)  1) "key:12"
    2) "key:8"
    3) "key:4"
    4) "key:14"
    5) "key:16"
    6) "key:17"
    7) "key:15"
    8) "key:10"
    9) "key:3"
   10) "key:7"
   11) "key:1"
redis 127.0.0.1:6379> scan 17
1) "0"
2) 1) "key:5"
   2) "key:18"
   3) "key:0"
   4) "key:2"
   5) "key:19"
   6) "key:13"
   7) "key:6"
   8) "key:9"
   9) "key:11"

BigKey案例

多大算大key

危害

内存不均，集群迁移困难
超时删除，大key删除作梗
网络流量阻塞

如何产生

定时任务
汇总统计
社交类

如何发现 `redis-cli --bigkeys`、`memory usage`

redis-cli--bigkeys
- 用法
  每隔 100 条 scan 指令就会休眠 0.1s，ops 就不会剧烈抬升，但是扫描的时间会变长
  - redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1
- 优势
  
  给出每种数据结构Top 1 bigkey，同时给出每种数据类型的键值个数+平均大小
- 不足
  
  想查询大于10kb的所有key，–bigkeys参数就无能为力了，需要用到memory usage来计算每个键值的字节数
memory usage
- 用法
  计算每个键值的字节数
  - MEMORY USAGE key [SAMPLES count]