注意点
使用规范
key的规范
- 以业务名为 key 前缀，用冒号隔开，以防止 key 冲突覆盖。如，
live:rank:1 - 确保 key 的语义清晰的情况下，key 的长度尽量小于30个字符。
- key 禁止包含特殊字符，如空格、换行、单双引号以及其他转义字符。
- Redis 的 key 尽量设置 ttl，以保证不使用的 key 能被及时清理或淘汰。
value的规范
如果大量存储 bigKey 是会有问题的，会导致慢查询，内存增长过快等等。
- 如果是 String 类型，单个 value 大小控制 10k 以内。
- 如果是 hash、list、set、zset 类型，元素个数一般不超过 5000。
过期时间尽量分散一点
因为 Redis 的数据是存在内存中的，而内存资源是很宝贵的。
我们一般是把 Redis 当做缓存来用，而「不是数据库」，所以 key 的生命周期就不宜太长久啦。
因此，你的 key，一般建议用「expire 设置过期时间」。
如果大量的key在某个时间点集中过期，到过期的那个时间点，Redis 可能会存在卡顿，甚至出现「缓存雪崩」现象，因此一般不同业务的 key，过期时间应该分散一些。
有时候，同业务的，也可以在时间上加一个随机值，让过期时间分散一些。
如何预防 Redis 问题？
资源规划
在部署 Redis 时，如果你可以提前做好资源规划，可以避免很多因为资源不足产生的问题。这方面我给你的建议有以下 3 点：
- 保证机器有足够的 CPU、内存、带宽、磁盘资源
- 提前做好容量规划，主库机器预留一半内存资源，防止主从机器网络故障，引发大面积全量同步，导致主库机器内存不足的问题
- 单个实例内存建议控制在 10G 以下，大实例在主从全量同步、RDB 备份时有阻塞风险
监控预警
监控预警是提高稳定性的重要环节，完善的监控预警，可以把问题提前暴露出来，这样我们才可以快速反应，把问题最小化。
这方面我给你的建议是：
- 做好机器 CPU、内存、带宽、磁盘监控，资源不足时及时报警，任意资源不足都会影响 Redis 性能
- 设置合理的 slowlog 阈值，并对其进行监控，slowlog 过多及时报警
- 监控组件采集 Redis INFO 信息时，采用长连接，避免频繁的短连接
- 做好实例运行时监控，重点关注 expired_keys、evicted_keys、latest_fork_usec 指标，这些指标短时突增可能会有阻塞风险
踩坑
暴露端口未设置密码
在某一天将服务器 redis 6380 绑定到了 0.0.0.0，第二天 redis 就挂了，报错如下:
1 2 | |
查看 redis.conf:
1 | |
dir 配置是没有问题的，redis 怎么会去访问 /etc/cron.d 这个危险的目录呢?
应该是被攻击了，攻击者想利用redis直接修改crontab配置,实现一些定时任务写入,从而去执行一些"特殊"命令(比如,挖矿等),甚至掌控服务器.
解决办法一:
所以启动任何线上服务的 redis 一定要设置密码进行保护
而且加密码也可以防止对数据库的误操作，比如将端口映射到了本地，如果没有密码保护的话，可以会在本地测试时对数据进行不当操作，造成数据丢失
在 redis 配置中添加 requirepass 配置
1 | |
解决办法2:
如果从机可以从内网访问主机，主机也没有外部访问的需求，那么可以将主机 bind 的 ip 改成主机的内网 ip 也可以