Redis再快也不能当内存用,特别是在分布式环境中
原理:当应用服务器与Redis的网络延迟在0.01ms的时候,可能不会有什么感觉。但当延时打到1.5ms的时候,滥用redis就会产生意想不到的结果。
场景:项目中有一些用户列表类接口,拼凑数据时使用逐个用户get的方式获取用户资料。假设列表为300,get300次至少就会发生0.45s的延迟。这显然是不能接受的。
解决:其实大多数时候直接用mget批量获取即可。
千万别用KEYS、HGETALL之类的操作
原理:KEYS会扫描Redis中所有键,且因为Redis的单线程操作,期间会阻塞所有其他操作。
场景:当键值很少的时候,并不会有任何感觉。但当键值数量达到十万级时,问题就会逐渐暴露出来。
解决:所以要么在设计上尽量避免KEYS类操作,使用诸如set集合结构代替。要么使用scan、hscan这类非阻塞操作。这一点在Redis官方文档里面其实已经有重点说明。 (我自己没看文档能怪谁呢科科)
详见:(1)Redis官方文档 KEYS (2)Redis命令参考(中文版) KEYS
使用slowlog get
命令查看阻塞redis的命令
当Redis性能下降时,可以使用redis命令查看慢查询日志。譬如
slowlog get 100
得到100条类似于下列结构的日志:
...
21) 1) "18416045" // 日志ID
2) "1523026632" // 日志时间戳
3) "35859" // 执行时间(微秒)
4) 1) "KEYS" // 所执行的命令
2) "xx:xx:xxxx:xxxxxxxxxxx*"
22) 1) "18416044"
2) "1523026632"
3) "35473"
4) 1) "KEYS"
2) "xx:xx:xxxxx:xxxxxx:*"
23) 1) "18416043"
2) "1523026632"
3) "31829"
4) 1) "HGETALL"
2) "xx:xx:xxxxx:xxxxx"
...
通过对慢日志的分析,可以找出当前程序到底被什么操作所拖累。
未完待续
转载请注明出处
《记一些最近踩的Redis的坑》https://www.ywlib.com/archives/138.html (from 一闻自习室)