Redis 学习(八)- 开发运维的“陷阱”

本篇文章来讲一讲开发运维中的"陷阱"

Linux 配置优化要点

  • 内存分配控制
    • vm.overcommit_memory 配置
  • THP
  • OOM killer
  • NTP (同步不同节点的时间)
  • ulimit (单个用户同时打开的文件数)
  • TCP backlog

flushall/flushdb 误操作快速恢复

以持久化文件作为恢复数据的媒介。

  • 借助 AOF 机制恢复
    • 避免AOF重写(调节auto-aof-rewrite-percentageauto-aof-rewrite-min-size
    • 将AOF文件中的flushall/flushdb去掉,同时用redis-check-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 存储)

猜你喜欢

转载自blog.csdn.net/melody_lql/article/details/88124392