参考自《redis开发与运维》
1. 内存消耗
1.1 内存使用统计
info memory指令，重点内容如下：
used_memory：redis内部数据所占内存总量
used_memory_rss：从操作系统角度看redis占用的内存总量
used_memory_peak：used_memory的峰值
mem_fragmentation_ratio：内存碎片率，used_memory_rss/info memory
如果内存碎片率大于1很多，则说明碎片化严重，如果小于1表示redis把内存里的数据交换到了硬盘，需要特别注意这个参数。
1.2 内存组成
（1）自身内存：很小，可忽略不计
（2）对象内存：包括redis中所有的key和对应的值所占的内存空间，因此应当避免过长的键，而值需要根据具体类型选择相应的编码。
（3）缓冲内存：
客户端缓冲：
输入输出缓冲区，输入缓冲区不可控，最大1G，输出缓冲区可以通过client-output-buffer-limit 参数控制。
普通客户端输出缓冲区：redis默认是不限制，一般普通客户端的内存消耗可以忽略不计，但某些指令如monitor就需要特别关注。
从客户端输出缓冲区：默认为client-output-buffer-limit slave256mb64mb60，当主从节点网络不好（如跨机房）或者主节点挂载多个从节点时，可能导致输出缓冲区过大。
订阅客户端输出缓冲区：默认为client-output-buffer-limit pubsub32mb8mb60，当消息生产者消息生成过快而消费速度过慢时，也有可能造成输出缓冲区溢出
复制积压缓冲区：redis2.8后才有，在主节点中存在，和所有从节点共享，用于实现部分复制功能，可以通过参数repl-backlog-size适当调大（如100M），它可以有效避免全量复制，默认为1M。
AOF缓冲区：用于redis在使用AOF方式时持久化数据到磁盘，无法控制，内存消耗取决于AOF持久时间和写入命令量。一般较小。
（4）内存碎片：根redis内存分配有关
redis默认使用jemalloc进行内存分配。它将内存空间划分为小、中、大三个范围，每个范围又划分为多个小的内存块单位，比如保存5k对象时，需要用8k的块进行存储，一定程度上会出现内存碎片。内存碎片率正常在1.03左右。
内存碎片出现场景：频繁做更新操作，如对已经存在的键做append、setrange操作；大量过期键删除，释放的空间不能有效利用时。
内存碎片解决方案：安全重启（单实例则直接重启服务，有主从集群等关系就切换节点为从节点然后重启服务）和数据对齐（数据尽量采用固定长度字符串或数字类型）
1.3 子进程内存消耗
当redis在执行AOF或RDB持久化时，需要fork一个子进程来进行持久化，而子进程的内存消耗和父进程相同，因此Linux出现了写时复制的技术，即父进程只有在写的时候才会复制相关页，而子进程读取父进程的内存进行持久化，即子进程读取的是fork时的父进程内存快照。
THP问题：即父进程在复制相关内存时由原来的4k（内存页单位）变成2M，如果父进程有大量写，会加重内存拷贝，从而造成过度内存消耗。因此需要关闭THP功能。
2. 内存管理
2.1 设置内存上限
maxmemory限制最大可用内存，可用防止redis的内存超过物理内存。
注意：maxmemory是redis实际使用的内存量，也就是used_memory统计的内存，即对象内存区域，不包括缓冲区、内存碎片，因此需要注意这部分内存溢出。
2.2 动态调整内存上限
通过config set maxmemory进行动态修改最大可用内存。
2.3 内存回收策略
2.3.1 删除过期键对象
redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的 key。
惰性删除，当客户端读取带有超时属性的键时，如果该键已经过时，那么删除该键值，并返回空。如果过期键一直没有读取，则不会及时释放。因此有了定时任务删除模式。
定期任务删除： Redis 默认会每秒进行10次（通过hz控制）过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。
从过期字典中随机 20 个 key；
删除这 20 个 key 中已经过期的 key；
如果过期的 key 比率超过 1/4，那就重复步骤 1；
该策略中采用了自适应快慢两种算法运行模式来回收键，流程如下：
1）定时任务在每个数据库空间随机检查20个键，发现过期时删除对应的键。
2）如果检索出来的键超过25%都是过期的键，那么将会循环执行回收逻辑操作 直到比例不足 25% 或运行到超时为止（为了避免过期扫描或者循环回收过度导致卡死，慢模式回收默认是25毫秒超时）
3）如果之前的回收键逻辑超时，则在 Redis出发内部事件之前再次以快模式运行回收过期任务，快模式下超时时间为1毫秒，且 2 秒内只能运行一次。
4）快慢模式的内部删除回收逻辑相同，只是超时事件不同罢了。
如果某一时刻，有大量key同时过期，Redis 会持续扫描过期字典，造成客户端响应卡顿，因此设置过期时间时，就尽量避免这个问题，在设置过期时间时，可以给过期时间设置一个随机范围，避免同一时刻过期。
2.3.2 内存溢出控制策略
（1）noeviction：默认策略，不删除数据，也拒绝写入，即redis变成只读操作。
（2）volatile-lru：根据LRU算法删除设置了超时属性的键，直到有足够的空间为止。如果没有可删除对象，回退到默认策略。
（3）allkeys-lru：根据lru算法删除键，不管数据是否设置了超时属性，直到腾出足够空间为止
（4）allkeys-random：随机删除所有键，直到腾出足够空间为止。
（5）volatile-random：随机删除过期键，直到腾出足够空间为止。
（6）volatile-ttl：根据键值对象的ttl属性删除最近将要过期数据，如果没有回退到默认策略
内存溢出控制策略可以采用config set maxmemory-policy{policy}动态配置。当Redis一直工作在内存溢出（used_memory>maxmemory）的状态下且设置非noeviction策略时，会频繁地触发回收内存的操作，影响Redis的性能。建议线上Redis内存工作在maxmemory>used_memory状态下，避免频繁内存回收开销。
3.内存优化
3.1 redisObject对象
Redis存储的所有值对象在内部定义为redisObject结构体，如下图所示：
高并发写入场景中，在条件允许的情况下，建议字符串长度控制在39字节以内，减少创建redisObject内存分配次数，从而提高性能。
3.2 缩减键值对象
降低Redis内存使用最直接的方式就是缩减键（key）和值（value）的长度。
·key长度：如在设计键时，在完整描述业务情况下，键值越短越好。
·value长度：值对象缩减比较复杂，一般为二进制数组或格式化存储（如json）。
在业务上精简对象，去掉不必要的属性
二进制数组在序列化时，选择更高效的序列化工具来降低字节数组大小
通用格式存储数据时，应考虑压缩速度和计算成本，如Google的Snappy压缩工具，降低存储空间。
3.3 共享对象池
共享对象池是指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。除了整数值对象，其他类型如list、hash、set、zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。
可以通过object refcount key 命令查看对象引用数。假设set foo 100，set bar 100这2个指令执行完后，这内存变成如下图所示：
注意：以下情况无法使用共享对象
内存回收策略为maxmemory+LRU时
值对象编码为ziplist时，因为ziplist使用压缩且内存连续的结构，对象共享判断成本过高
3.4 字符串优化
redis没有采用原生C的字符串类型，而是进行了封装，包括字符串已用长度、空闲长度、字符数组3个部分组成。内部实现空间预分配机制。第一次set时，正常分配，第二次使用append或setrange时，会进行空间的动态扩展，类似Java的ArrayList动态扩容机制，造成内存空间的浪费和内存碎片化加剧。因此在开发时，不要使用append或setrange指令。直接使用 set
字符串重构，对于json作为值时，可以使用hash结构进行重构优化。这样能提高内存使用率，可以使用hmget和hmset读取和修改部分字段，降低网络开销。
3.5 编码优化
在redis中，每种类型都对应一个或多个底层数据结构，我们称之为值的编码，编码不同将直接影响数据的内存占用和读写效率。可通过object encoding key来查询。
编码类型在redis写入数据时自动完成，这个过程是不可逆的，转化规则只能从小内存编码向大内存编码转换。
3.5.1 ziplist编码
ziplist编码主要目的是为了节约内存，因此所有数据都是采用线性连续的内存结构。ziplist编码是应用范围最广的一种，可以分别作为hash、list、zset类型的底层数据结构实现。
ziplist压缩编码的性能表现跟值长度和元素个数密切相关，正因为如此Redis提供了{type}-max-ziplist-value和{type}-max-ziplist-entries相关参数来做控制ziplist编码转换。最后再次强调使用ziplist压缩编码的原则：追求空间和时间的平衡，即减少内存空间的占用，但读写性能会降低。
针对性能要求较高的场景使用ziplist，建议长度不要超过1000，每个元素大小控制在512字节以内。
命令平均耗时使用info Commandstats命令获取，包含每个命令调用次数、总耗时、平均耗时，单位为微秒。
3.6 控制键的数量
当使用Redis存储大量数据时，通常会存在大量键，过多的键同样会消耗大量内存。Redis本质是一个数据结构服务器，它为我们提供多种数据结构，如hash、list、set、zset等。使用Redis时不要进入一个误区，大量使用get/set这样的API，把Redis当成Memcached使用。对于存储相同的数据内容利用Redis的数据结构降低外层键的数量，也可以节省大量内存。
使用hash重构后节省内存量效果非常明显，特别对于存储小对象的场景，下面分析这种内存优化技巧的关键点：
（1）hash类型节省内存的原理是使用ziplist编码，如果使用hashtable编码方式反而会增加内存消耗。
（2）ziplist长度需要控制在1000以内，否则读写长列表会导致CPU消耗严重，得不偿失。
（3）ziplist适合存储小对象，对于大对象不但内存优化效果不明显还会增加命令操作耗时。
（4）需要预估键的规模，从而确定每个hash结构需要存储的元素数量。
（5）根据hash长度和元素大小，调整hash-max-ziplist-entries和hash-max-ziplist-value参数，确保hash类型使用ziplist编码。
缺点：
hash重构后所有的键无法再使用超时（expire）和LRU淘汰机制自动删除，需要手动维护删除。
对于大对象，如1KB以上的对象，使用hash-ziplist结构控制键数量反而得不偿失。
优点：
对于大量小对象的存储场景，非常适合使用ziplist编码的hash类型控制键的规模来降低内存。
转自：https://blog.csdn.net/zhaocuit/article/details/90548716