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 一闻自习室)