Redis优化

Redis优化Redis 键与值优化KeyKey命名规范为什么不要使用超长KeyValue值底层编码BigKey 优化官方定义BigKey核心危害BigKey解决方案热点Key优化批处理优化MsetPipeline集群下的批处理服务端优化持久化配置慢查询命令及安全配置内存配置内存缓冲区集群最佳实践集群完整性问题带宽问题Redis 键与值优化Keyint / embstr / raw仅仅是String类型Value的编码依托redisObject结构体Redis哈希表内的顶层Key只是裸SDS没有外层redisObject不存在这套编码不受44字节阈值限制OBJECT ENCODING key查询的是Value的编码和Key字符串本身无关。Key命名规范标准格式业务模块:数据类型:唯一标识示例user:post:101、stock:voucher:2001:0约束统一小写分隔符只用英文冒号:禁止空格、特殊符号尽量缩短Key长度但不是为了embstr为什么不要使用超长KeyKey本身是SDS字符串字符越长内存占用越高海量Key场景内存开销持续放大Redis需要对Key做哈希运算字符串越长CPU计算耗时越高增大AOF/RDB持久化文件体积增加落盘、加载、主从同步压力客户端与Redis网络传输时占用更多带宽。Value值底层编码String类型的Value由redisObject SDS封装存在3种编码int存放可以转为64位长整型的字符串12345不创建SDS内存开销最小优先级最高。embstr字符串有效长度 ≤ 44字节redisObject和SDS一次性连续内存分配一次malloc内存碎片少访问效率高。raw字符串有效长度 44字节redisObject与SDS分开两次内存分配开销更大。⚠️补充特性embstr属于只读模式执行APPEND、SETRANGE等修改命令时会自动转化为raw编码。BigKey 优化官方定义BigKey指某个顶层Key对应的Value体量过大StringValue大小10KBHash/List/Set/ZSet集合内元素数量5000例子SET info 10MB文本→ Key很短但属于BigKey超长名称的小型Hash仅十几个字段不属于BigKey。BigKey核心危害阻塞Redis主线程致命Redis单线程模型读取、删除、序列化持久化大Value产生大量内存拷贝阻塞全部业务请求瞬时打爆网络带宽频繁分配释放大块内存产生严重内存碎片Redis Cluster集群迁移slot时迁移BigKey耗时极长造成槽位不可用。BigKey解决方案数据拆分大String、大库存、大集合进行分片拆分例秒杀单热点库存Key → 拆分为多个分段库存Key也就是分段库存Lua方案打散热点同时规避BigKey。渐进式删除禁止直接DEL大集合使用SCAN/HSCAN/ZSCAN分批遍历删除元素平缓释放内存。控制集合生命周期合理设置TTL避免数据无限膨胀。热点Key优化BigKey单个Value太大HotKey同一个Key被海量并发请求访问解决方案本地多级缓存Caffeine做请求拦截数据分片拆分分段库存就是典型Redis集群读写分离分担读压力。批处理优化批量处理减少网络传输的耗时但是一次处理太多把带宽打满造成网络阻塞。MsetmsethmseyPipeline大量数据导入方式管道。pipeline多个命令没有原子性会被其他pipeline阻塞原生M操作是原子性的所以操作速度会更快。Pipelinepipelinejdeis.pipelined();//创建管道pileline.set(key,value);//放入命令到管道pipeline.sync();//批量执行集群下的批处理如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令而此时Redis是一个集群那批处理命令的多个key必须落在一个插槽中否则就会导致执行失败。两种方法手写jdeisSpring客户端解决了批量插入默认lettus 服务端优化持久化配置慢查询解决慢查询避免适用一些命令解决BigKey问题。命令及安全配置ssh免密登录本地生成ssh公钥私钥私钥放在本地把公钥放在服务器.ssh目录下并且重命名为authorized_keys意思是已授权密钥。redis漏洞将公钥写入文件foot.txt再连接redis设置键值对把这个文件内容设置为valuecat foot.txt redis-cli -h 192.168.1.11 -x set crackit配置持久化目录config set dir/root/.ssh/配置持久化文件名config set dbfilename “authorized_keys”执行save一旦持久化就会把密钥写入文件密钥就被授权了。内存配置当Redis内存不足时可能导致Key频繁被删除、响应时间变长、QPS等不稳定问题。当内存使用率达到90%以上时就需要快速定位到内存占用原因。数据内存redis最主要的部分存储键值信息。主要问题是BigKey、内存碎片定期重启主从或者集群分批重启。进程内存redis主进程本身运行肯定需要占用内存如代码、常量池等等这部分内存大约几兆在大多数生产环境中与redis数据占用的内存相比可以忽略。缓冲区内存一般包括客户端缓冲区、AOF缓冲区、复制缓冲区等。客户端缓冲区又包括输入和输出缓冲区两种。这部分内存占用波动较大不当适用BigKey可能导致内存溢出。查看内存分配状态info memorymemory xxxmemory stats # 查看内粗状态memory doctor # 判断内存问题内存缓冲区复制缓冲区主从复制的repl_backlog_buf如果太小可能导致频繁的全量复制影响性能。通过repl_backlog-size来设置默认1mb。AOF缓冲区AOF刷盘之前的缓冲区域AOF执行rewrite的缓冲区。无法设置容量上限。客户端缓冲区分为输入缓冲区和输出缓冲区输入最大1G且不能设置。输出缓冲区可以。client-output-buffer-limit配置详解该命令用于限制不同类别客户端的输出缓冲区大小防止因客户端处理速度过慢慢客户端导致服务端内存耗尽。其配置格式为client-output-buffer-limit class hard limit soft limit soft secondsclass客户端类别。可选值为normal普通客户端。slave从节点副本客户端用于主从复制。pubsub订阅了至少一个频道的Pub/Sub模式客户端。hard limit硬限制。如果客户端输出缓冲区大小超过此值无论何种情况连接都会被立即关闭。soft limit软限制。soft seconds软限制持续时间秒。触发规则如果输出缓冲区大小超过hard limit连接立即关闭。如果输出缓冲区大小超过soft limit并且持续了soft seconds秒连接也会被关闭。配置示例# 普通客户端硬限制0表示不限制软限制32MB持续10秒则断开client-output-buffer-limit normal000# 从节点客户端硬限制256MB软限制64MB持续60秒client-output-buffer-limit slave 256mb 64mb60# Pub/Sub客户端硬限制32MB软限制8MB持续60秒client-output-buffer-limit pubsub 32mb 8mb60监控与调优通过CLIENT LIST命令查看客户端的omem(output buffer memory) 字段了解输出缓冲区使用情况。若频繁出现因输出缓冲区超限导致的连接断开需检查客户端消费能力或适当调整限制值。集群最佳实践集群完整性问题在redis默认配置中一个插槽不可用则整个集群停止对外服务cluster-require-full-coverage yes带宽问题集群接待你之间会不断的相互ping来确定集群中其他节点的状态。每次ping携带的信息至少包括插槽信息集群状态信息集群中节点越多集群状态信息数据量也越大10个节点的相关信息可能可以达到1kb此时每次集群互通需要的带宽会非常高。解决途径避免大集群集群节点数不要台服哦最好少于1000如果业务庞大则建立多个集群。避免在单个物理机中运行太多redis实例。配置合适的cluster-node-timeout值。注意单体redis主从redis已经能达到万级别的QPS并且也具备很强的高可用特性。如果主从能满足业务需求的情况下尽量不搭建redis集群。