Redis教程

【Redis 开发与运维】开发运维的“陷阱”

本文主要是介绍【Redis 开发与运维】开发运维的“陷阱”,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

文章目录

  • 一、Linux 配置优化
    • 内存分配控制
    • OOM killer
    • 使用 NTP
  • 二、flushall / flushdb 误操作
    • 缓存与存储
    • 借助 AOF 机制恢复
    • RDB 有什么变化
  • 三、安全的 Redis
    • Redis 密码机制
    • 伪装危险命令
    • 防火墙
    • 定期备份数据
    • 不使用默认端口
    • 使用非 root 用户启动
  • 四、处理 bigkey
    • bigkey 的危害
    • 如何发现
    • 如何删除
  • 五、寻找热点 key
    • 统计热点 key
    • 解决热点 key 问题


一、Linux 配置优化

内存分配控制

  • Redis 设置合理的 maxmemory,保证机器有 20% ~ 30% 的闲置内存。
  • 集中化管理 AOF 重写和 RDB 的 bgsave。
  • 设置 vm.overcommit_memory=1,防止极端情况下会造成 fork 失败。

OOM killer

  • OOM killer 会在可用内存不足时选择性地杀掉用户进程。
  • 对于 Redis 所在的服务器来说,可以将所有 Redis 的 oom_adj 设置为最低值或者稍小的值,降低被 OOM killer 杀掉的概率。

使用 NTP

  • NTP(Network Time Protocol,网络时间协议)是一种保证不同机器时钟一致性的服务。一般公司里都会有 NTP 服务用来提供标准时间服务,从而达到纠正时钟的效果。

二、flushall / flushdb 误操作

  • Redis 的 flushall / flushdb 命令可以做数据清除,对于 Redis 的开发和运维人员有一定帮助,然而一旦误操作,它的破坏性也是很明显的。

缓存与存储

  • 被误操作 flush 后,根据当前 Redis 是缓存还是存储使用策略有所不同:
    • 缓存:对于业务数据的正确性可能造成损失还小一点,因为缓存中的数据可以从数据源重新进行构建。
    • 存储:对业务方可能会造成巨大的影响,如果没有提前做业务降级,那么最终反馈到用户的应用可能就是报错或者空白页面等。

借助 AOF 机制恢复

  • Redis 执行了 flush 操作后,AOF 持久化文件会受到什么影响呢,如下:
    • appendonly no:对 AOF 持久化没有任何影响,因为根本不存在 AOF 文件。
    • appendonly yes:只不过在 AOF 文件中追加了一条 flushall 记录。
  • 也就是说,虽然 Redis 中的数据被清掉了,但是 AOF 文件还保存着 flush 操作之前完整的数据,这对恢复数据是很有帮助的。

RDB 有什么变化

Redis 执行了 flushall 操作后,RDB持久化文件会受到什么影响呢?

  • 1)如果没有开启 RDB 的自动策略,也就是配置文件中没有类似如下配置

    save 900 1 
    save 300 10 
    save 60 10000
    
  • 那么除非手动执行过 save、bgsave 或者发生了主从的全量复制,否则 RDB 文件也会保存 flush 操作之前的数据,可以作为恢复数据的数据源。注意问题如下:

    • 防止手动执行 save、bgsave,如果此时执行 save、bgsave,新的 RDB 文件就不会包含 flush 操作之前的数据,被老的RDB文件进行覆盖。
    • RDB 文件中的数据可能没有 AOF 实时性高,也就是说,RDB 文件很可能很久以前主从全量复制生成的,或者之前用 save、bgsave 备份的。
  • 2)如果开启了 RDB 的自动策略,由于 flush 涉及键值数量较多,RDB 文件会被清除意味着使用 RDB 恢复基本无望。


三、安全的 Redis

  • 数据丢失对于很多 Redis 的开发者来说是致命的,经过相关机构的调查发现,被攻击的 Redis 有如下特点:
    • Redis 所在的机器有外网 IP
    • Redis 以默认端口 6379 为启动端口,并且是对外网开放的
    • Redis 以 root 用户启动的 Redis 没有设置密码
    • Redis 的 bind 设置为 0.0.0.0 或者 “”
  • 将从下面几个方面介绍如何保证 Redis 的安全。

Redis 密码机制

  • Redis 提供了 requirepass 配置为 Redis 提供密码功能,如果添加这个配置,客户端就不能通过 redis-cli -h {ip} -p {port} 来执行命令。

伪装危险命令

  • Redis 中包含了很多“危险”命令,一旦生产上错误使用或者误操作,后果不堪设想,例如:
    • keys:如果键值较多,存在阻塞 Redis 的可能性
    • flushall/flushdb:数据全部被清除
    • save:如果键值较多,存在阻塞 Redis 的可能性
    • debug:个例如 debug reload 会重启 Redis
    • config:config 应该交给管理员使用
    • shutdown:停止 Redis
  • Redis 提供了 rename-command 配置解决了这个问题,例如添加如下配置:
    rename-command flushall abcabcabc
    
  • 那么再执行 flushall 的话,会收到 Redis 不认识 flushall 的错误提示,说明成功的对 flushall 进行了伪装。
  • 而如果执行 abcabcabc ,那么就可以实现 flushall 功能了。

防火墙

  • 可以使用防火墙限制输入和输出的 IP 或者 IP 范围、端口或者端口范围。

定期备份数据

  • 定期备份数据能够在一定程度挽回一些损失,定期备份持久化数据是一个比较好的习惯。

不使用默认端口

  • Redis 的默认端口是 6379,不使用默认端口从一定程度上可降低被入侵者发现的可能性,因为入侵者通常本身也是一些攻击程序。

使用非 root 用户启动

  • root 用户作为管理员,权限非常大。如果被入侵者获取 root 权限后,就可以在这台机器以及相关机器所以操作。所以建议在启动 Redis 服务的时候使用非 root 用户启动。

四、处理 bigkey

  • bigkey 是指 key 对应的 value 所占的内存空间比较大,例如一个字符串类型的 value 可以最大存到 512MB,一个列表类型的 value 最多可以存储 2^32 - 1 个元素。如果按照数据结构来细分的话,一般分为两种:
    • 字符串类型:体现在单个 value 值很大,一般认为超过 10 KB 就是 bigkey,但这个值和具体的 OPS 相关。
    • 非字符串类型:哈希、列表、集合、有序集合,体现在元素个数过多

bigkey 的危害

  • 内存空间不均匀:例如在 Redis 集群中,bigkey 会造成节点的内存空间使用不均匀。
  • 超时阻塞:由于 Redis 单线程的特性,操作 bigkey 比较耗时,也就意味着阻塞 Redis 可能性增大。
  • 网络阻塞:每次获取 bigkey 产生的网络流量较大。

如何发现

  • redis-cli --bigkeys 可以命令统计 bigkey 的分布。但是生产环境中,开发和运维人员更希望自己可以定义 bigkey 的大小而且更希望找到真正的 bigkey 都有哪些 ,这样才可以去定位、解决、优化问题。
  • 判断一个 key 是否为 bigkey,只需要执行 debug object key 查看 serializedlength 属性即可,它表示 key 对应的 value 序列化之后的字节数。
  • 在实际的生产环境中发现 bigkey 的两种方式如下:
    • 被动收集:许多开发人员确实可能对 bigkey 不了解或重视程度不够,但是这种 bigkey 一旦大量访问,很可能就会带来命令慢查询和网卡跑满问题,开发人员通过对异常的分析通常能找到异常原因可能是 bigkey,这种方式并不推荐,但是在实际生产环境中却大量存在,建议修改 Redis 客户端,当抛出异常时打印出所操作的 key,方便排查 bigkey 问题。
    • 主动检测scan + debug object,如果怀疑存在bigkey,可以使用scan命令渐进的扫描出所有的key,分别计算每个 key 的 serializedlength,找到对应 bigkey 进行相应的处理和报警,这种方式是比较推荐的方式。

如何删除

  • 首先,无论是什么数据结构,del 命令都能将其删除。但是经过上面的分析你一定不会这么做,删除 bigkey 通常来说会阻塞 Redis 服务
  • 这个时候就需要 scan 命令的若干类似命令拿出来:sscan、hscan、zscan
  • string
    • 对于 string 类型使用 del 命令一般不会产生阻塞
  • hash、list、set、sorted set
    • 下面以 hash 为例子,使用 hscan 命令,每次获取部分(例如 100 个)field-value,再利用 hdel 删除每个 field(为了快速可以使用 Pipeline):
    	public void delBigHash(String bigKey) {
            // 游标
            Jedis jedis = new Jedis("127.0.0.1", 6379);
            String cursor = "0";
            while (true) {
                ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan(bigKey, cursor, 
                		new ScanParams().count(100));
                // 每次扫描后获取新的游标
                cursor = scanResult.getStringCursor();
                // 获取扫描结果
                List<Map.Entry<String, String>> list = scanResult.getResult();
                if (list == null || list.size() == 0) {
                    continue;
                }
    
                String[] fields = getFieldsFrom(list);
                // 删除多个field
                jedis.hdel(bigkey, fields);
                // 游标为0时停止
                if (cursor.equals("0")) {
                    break;
                }
            }
    
            //最终删除key
            jedis.del(bigKey);
        }
        /**
         * 获取 field 数组
         * @param list
         * @return
         */
        private String[] getFieldsFrom(List<Map.Entry<String, String>> list) {
            List<String> fields = new ArrayList<>();
            for (Map.Entry<String, String> entry : list) {
                fields.add(entry.getKey());
            }
            return fields.toArray(new String[fields.size()]);
        }
    
  • Redis 4.0 新增了非常实用的惰性删除 lazy free 特性,从根本上解决了 bigkey(主要指定元素较多集合类型key)删除的风险

五、寻找热点 key

热门新闻事件或商品通常会给系统带来巨大的流量,对存储这类信息的 Redis 来说却是一个巨大的挑战。以 Redis Cluster 为例,它会造成整体流量的不均衡,个别节点出现 OPS 过大的情况,极端情况下热点 key 甚至会超过 Redis 本身能够承受的 OPS,因此寻找热点 key 对于开发和运维人员非常重要。下面从以下几个方面分析热点 key。

统计热点 key

  • 客户端
    • 客户端其实是距离 key “最近” 的地方,因为 Redis 命令就是从客户端发出的,例如在客户端设置全局字典(key 和调用次数),每次调用 Redis 命令时,使用这个字典进行记录。
    • 使用客户端进行热点 key 的统计非常容易实现,但同时问题也非常多:
      • 无法预知 key 的个数,存在内存泄露的危险。
      • 对于客户端代码有侵入,各个语言的客户端都需要维护此逻辑,维护成本较高。
      • 只能了解当前客户端的热点 key,无法实现规模化运维统计。
  • 代理端
    • 像 Twemproxy、Codis 这些基于代理的 Redis 分布式架构,所有客户端的请求都是通过代理端完成的。此架构是最适合做热点 key 统计的,因为代理是所有 Redis 客户端和服务端的桥梁。但并不是所有Redis都是采用此种架构。
  • Redis 服务端
    • 使用 monitor 命令统计热点 key 是很多开发和运维人员首先想到,monitor 命令可以监控到 Redis 执行的所有命令
    • 利用 monitor 命令就可以统计出一段时间内的热点 key 排行榜、命令排行榜、客户端分布等数据。
    • 但是此种方法会有两个问题:
      • monitor 命令在高并发条件下,会存在内存暴增和影响 Redis 性能的隐患,所以此种方法适合在短时间内使用。
      • 只能统计一个 Redis 节点的热点 key,对于 Redis 集群需要进行汇总统计。
  • 机器
    • Redis 客户端使用 TCP 协议与服务端进行交互,通信协议采用的是 RESP。如果站在机器的角度,可以通过对机器上所有 Redis 端口的 TCP 数据包进行抓取完成热点 key 的统计

解决热点 key 问题

  • 拆分复杂数据结构:如果当前 key 的类型是一个二级数据结构,例如哈希类型。如果该哈希元素个数较多,可以考虑将当前 hash 进行拆分,这样该热点 key 可以拆分为若干个新的 key 分布到不同 Redis 节点上,从而减轻压力。
  • 迁移热点key:以 Redis Cluster 为例,可以将热点 key 所在的 slot 单独迁移到一个新的 Redis 节点上,但此操作会增加运维成本。
  • 本地缓存加通知机制:可以将热点 key 放在业务端的本地缓存中,因为是在业务端的本地内存中,处理能力要高出 Redis 数十倍,但当数据更新时,此种模式会造成各个业务端和 Redis 数据不一致,通常会使用发布订阅机制来解决类似问题。

来源:《Redis 开发与运维》第 12 章 开发运维的“陷阱”

这篇关于【Redis 开发与运维】开发运维的“陷阱”的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!