本篇文章来讲一讲开发运维中的"陷阱"
Linux 配置优化要点
- 内存分配控制
- vm.overcommit_memory 配置
- THP
- OOM killer
- NTP (同步不同节点的时间)
- ulimit (单个用户同时打开的文件数)
- TCP backlog
flushall/flushdb 误操作快速恢复
以持久化文件作为恢复数据的媒介。
- 借助 AOF 机制恢复
- 避免AOF重写(调节
auto-aof-rewrite-percentage
和auto-aof-rewrite-min-size
) - 将AOF文件中的flushall/flushdb去掉,同时用
redis-check-aof
检测下文件是否正确
- 避免AOF重写(调节
- RDB 变化
- 避免 bgsave 重写RDB文件
- RDB 方式会有延迟,如果没有开启AOF,可以使用(有总比没有好)
- 从节点变化 (和主节点没有区别)
安全的 Redis 如何设计
笔者曾经就被攻击过,心塞
- 被攻击的 Redis 有那些特点
- Redis 所在的机器有外网IP
- Redis 以默认端口6379为启动端口,并且是对外开放的
- Redis 是以root 用户启动的
- Redis 没有设置密码
- Redis 的bind设置为0.0.0.0 或 “”
- 具体攻击的细节可以问度娘,这里不赘述。下面讲讲从那些方面防范:
- 密码机制
- 伪装危险命令(rename-command)
- 防火墙(iptables)
- bind IP
- 定期备份数据
- 不使用默认端口
- 使用非root用户启动
处理bigkey的方案
bigkey是指key对应的value所占的内存空间比较大,例如一个字符串类型的value可以最大存到512MB。
- 非字符串类型:体现在单个value值很大,一般认为超过10kB就是bigkey。
- 非字符串累心:体现在元素个数过多
bigkey有那些危害
- 内存空间不均匀
- 超时阻塞
- 网络阻塞
如何发现
- redis-cli --bigkeys 查看分布
如何删除
- string 类型 用del, 其他类型用 sscan、hscan 等命令范围获取后在删除
寻找热点 key
- 可以从那些方面获取
- 客户端
- 代理端
- Redis 服务端
- 机器
- 如何处理热点key
- 拆分复杂的数据结构
- 迁移热点key(比如可以用Redis cluster 单独 slot 存储)