‘壹’ redis是干嘛的
Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
Redis是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C+，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。
相关内容：
下面是官方的bench-mark数据：
测试完成了50个并发执行100000个请求。
设置和获取的值是一个256字节字符串。
Linux box是运行Linux 2.6,这是X3320 Xeon 2.5 ghz。
文本执行使用loopback接口（127.0.0.1)。
结果：读的速度是110000次／s,写的速度是81000次／s。
‘贰’ redis中的数据占用内存大小分析
如今越来越来的系统中使用 redis 作为缓存系统，但是随着用户量的增长，业务数据不断增多，redis服务器的内存空间有可能会到瓶颈了，及时观察redis中的各种键内存占用多少，会方便我们评估何时升级redis服务器规格，以及对于是否需要进行程序优化来设计合理的存储结构都会有很大帮助，下面给大家介绍两款工具 rdr 和 redis-rdb-tools ，可以很好的满足我们的需要
详细使用参考官方仓库：https://github.com/xueqiu/rdr
rdr提供了linux/OSX/Windows下的可执行文件，直接点击下载，我这里演示Windows下的使用方式
下载下来后存储到d:/dev路径下
1.首先要去redis服务器端将rdb文件复制到本地，为了方便，我将rdb文件放到了rdr工具所在目录
这里再说下redis rdb文件该怎么找到，通过查看redis服务器配置文件 redis.conf ，搜索 dbfilename 可以快速定位到该配置，按照路径就可以找到redis rdb备份文件了
2.在rdr工具所在的路径下打开命令行窗口，执行指令
可以看到指令执行成功后，在本地启动了server，监听端口8080
3.打开浏览器，访问http://localhost:8080/，能看到详细的内存占用数据报告，包括键数量、不同的数据类型、元素计数等
不过通过网页版的数据报告中有个小问题，对于redis中的不同数据库没有明显的区分展示~，混在一起，不是太清晰
详细使用参考官方仓库：https://github.com/sripathikrishnan/redis-rdb-tools/
1.安装python环境，我这里安装了python2.7.15
2.通过pip安装redis-rdb-tools
我这里python-lzf库没有安装成功，不过不影响实际使用，这个库是为了加速rdb文件解析速度~
3.安装完成后就可以在命令行中使用了，输入指令生成内存报告文件
等待一段时间，命令阻塞执行完成后，就会在-f参数指定的路径下生成对应的文件
用excel打开生成的csv文件，可以看到详细的统计结果，包含了所有数据库下所有key的内存占用情况~
redis-rdb-tools中还带了一个很有用的命令，能帮助我们直接查询单个key的内存占用情况，命令格式如下
执行测试下效果，可以看到命令执行完成后，直接回显出指定key对应的内存占用情况了
注意该操作在生产环境下慎用，视key大小情况再行决定是否执行，有可能会阻塞执行很长时间才能计算出结果~
‘叁’ Redis --- 八种数据类型（基本命令）
String、Hash、List、Set和Zset。
等同于java中的， Map<String,String> string 是redis里面的最基本的数据类型，一个key对应一个value。
应用场景 ：String是最常用的一种数据类型，普通的key/value存储都可以归为此类，如用户信息，登录信息和配置信息等；
实现方式 ：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作（自增自减等原子操作）时会转成数值型进行计算，此时redisObject的encoding字段为int。
Redis虽然是用C语言写的，但却没有直接用C语言的字符串，而是自己实现了一套字符串。目的就是为了提升速度，提升性能。 Redis构建了一个叫做简单动态字符串（Simple Dynamic String），简称SDS。
Redis的字符串也会遵守C语言的字符串的实现规则，即 最后一个字符为空字符。然而这个空字符不会被计算在len里头。
Redis动态扩展步骤：
Redis字符串的性能优势
常用命令 ：set/get/decr/incr/mget等，具体如下；
ps：计数器（字符串的内容为整数的时候可以使用），如 set number 1。
补充：
等同于java中的： Map<String,Map<String,String>> ，redis的hash是一个string类型的field和value的映射表， 特别适合存储对象。 在redis中，hash因为是一个集合，所以有两层。第一层是key：hash集合value，第二层是hashkey：string value。所以判断是否采用hash的时候可以参照有两层key的设计来做参考。并且注意的是， 设置过期时间只能在第一层的key上面设置。
应用场景 ：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；
实现方式 ：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如，Key是用户ID, value是一个Map。 这个Map的key是成员的属性名，value是属性值 。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。 当前HashMap的实现有两种方式 ：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时redisObject的encoding字段为int。
常用命令 ：hget/hset/hgetall等，具体如下：
等同于java中的 Map<String,List<String>> ，list 底层是一个链表，在redis中，插入list中的值，只需要找到list的key即可，而不需要像hash一样插入两层的key。 list是一种有序的、可重复的集合。
应用场景 ：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；
实现方式 ：Redis list的实现为一个 双向链表 ，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括 发送缓冲队列 等也都是用的这个数据结构。
常用命令 ：lpush/rpush/lpop/rpop/lrange等，具体如下：
性能总结 :
它是一个字符串链表，left、right都可以插入添加。
等同于java中的 Map<String,Set<String>> ，Set 是一种无序的，不能重复的集合。并且在redis中，只有一个key它的底层由hashTable实现的，天生去重。
应用场景 ：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动去重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且 set提供了判断某个成员是否在一个set集合内的重要接口 ，这个也是list所不能提供的；如保存一些标签的名字。标签的名字不可以重复，顺序是可以无序的。
实现方式 ：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
常用命令 ：sadd/spop/smembers/sunion等，具体如下：
ZSet(Sorted Set：有序集合) 每个元素都会关联一个double类型的分数score，分数允许重复，集合元素按照score排序（ 当score相同的时候，会按照被插入的键的字典顺序进行排序 ），还可以通过 score 的范围来获取元素的列表。
应用场景 ：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以 通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。 当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
底层实现 ： zset 是 Redis 提供的一个非常特别的数据结构，常用作排行榜等功能，以用户 id 为 value ，关注时间或者分数作为 score 进行排序。实现机制分别是 zipList 和 skipList 。规则如下：
zipList：满足以下两个条件
skipList：不满足以上两个条件时使用跳表、组合了hash和skipList
为什么用skiplist不用平衡树？
主要从内存占用、对范围查找的支持和实现难易程度这三方面总结的原因。
拓展：mysql为什么不用跳表？
常用命令 ：zadd/zrange/zrem/zcard等；
官网地址： https://redis.io/commands/geoadd
可以用来推算两地之间的距离，方圆半径内的人。
关于经度纬度的限制： https://www.redis.net.cn/order/3685.html
一般我们使用Hyperloglog做基数统计。
什么是基数？就是一个集合中不重复的数的个数。
集合A：{1,3,5,7,9,7}
集合B：{1,3,5,7,9}
AB集合的基数都是5
应用：统计网站的访问量（一个人访问网站很多次仍然算作一次）。
优点：占用的内存是固定的，找2^64次方个数的基数，只需要12KB内存。
缺点：有0.81%的错误率，可以忽略不计
概述： bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。 我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
应用场景: 适合需要保存状态信息（比如是否签到、是否登录...）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
针对上面提到的一些场景，这里进行进一步说明。
使用场景一：用户行为分析 很多网站为了分析你的喜好，需要研究你点赞过的内容。
使用场景二：统计活跃用户
使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1
那么我该如果计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只有有一天在线就称为活跃)，有请下一个 redis 的命令
使用场景三：用户在线状态
对于获取或者统计用户在线状态，使用 bitmap 是一个节约空间效率又高的一种方法。
只需要一个 key，然后用户 ID 为 offset，如果在线就设置为 1，不在线就设置为 0。
补充 ：
巨人的肩膀：
https://www.cnblogs.com/Small-sunshine/p/11687809.html
https://mp.weixin.qq.com/s/CMu7oXVIKp2s-PXTdMlimA
‘肆’ redis的数据是存在内存里吗
Redis就是基于内存可持久化的key-value数据库。
1、性能问题，Hashmap存储大量数知据时需要不断扩容，Redis支持2的32次方个key，每个key或者value大小最大512M。
2、Hashmap是线程不安道全的，redis因为操作原子性不需要考虑这个。
3、Redis可持久化，Hashmap虽然也可以序列专化，但是Java的序列化因为安全问题说是要废除了，效率也没有Redis高，而且Redis有多属种持久化策略。
4、Redis可扩展可分布式部署。
(4)内存存储redis扩展阅读：
redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。
save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。
appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。
‘伍’ redis怎么进行内存管理
当mem_fragmentation_ratio>1时，说明used_memory_rss-used_memory多出的部分内存并没有用于数据存储，而是被内存碎片所消耗，如果两者相差很大，说明碎片率严重。
当mem_fragmentation_ratio<1时，这种情况一般出现在操作系统把Redis内存交换(Swap)到硬盘导致，出现这种情况时要格外关注，由于硬盘速度远远慢于内存，Redis性能会变得很差，甚至僵死。Redis进程内消耗主要包括：自身内存+对象内存+缓冲内存+内存碎片，其中Redis空进程自身内存消耗非常少，通常used_memory_rss在3MB左右，used_memory在800KB左右，一个空的Redis进程消耗内存可以忽略不计。
◆ 缓冲内存主要包括： 客户端缓冲、复制积压缓冲区、AOF缓冲区。客户端缓冲指的是所有接入到Redis服务器TCP连接的输入输出缓冲。输入缓冲无法控制，最大空间为1G，如果超过将断开连接。
◆ 复制积压缓冲区： Redis在2.8版本之后提供了一个可重用的固定大小缓冲区用于实现部分复制功能，根据repl-backlog-size参数控制，默认1MB。对于复制积压缓冲区整个主节点只有一个，所有的从节点共享此缓冲区，因此可以设置较大的缓冲区空间，如100MB，这部分内存投入是有价值的，可以有效避免全量复制AOF缓冲区：这部分空间用于在Redis重写期间保存最近的写入命令，AOF缓冲区空间消耗用户无法控制，消耗的内存取决于AOF重写时间和写入命令量，这部分空间占用通常很小。
Redis默认的内存分配器采用jemalloc， 可选的分配器还有：glibc、tcmalloc 。内存分配器为了更好地管理和重复利用内存，分配内存策略一般采用固定范围的内存块进行分配。内存碎片问题虽然是所有内存服务的通病，但是jemalloc针对碎片化问题专门做了优化，一般不会存在过度碎片化的问题，正常的碎片率(mem_fragmentation_ratio)在1.03左右。
一般以下场景容易出现高内存碎片问题：
● 频繁做更新操作，例如频繁对已存在的键执行append、setrange等更新操作。大量过期键删除，键对象过期删除后，释放的空间无法得到充分利用，导致碎片率上升。
出现高内存碎片问题时常见的解决方式如下：
● 数据对齐：在条件允许的情况下尽量做数据对齐，比如数据尽量采用数字类型或者固定长度字符串等，但是这要视具体的业务而定，有些场景无法做到。
● 安全重启：重启节点可以做到内存碎片重新整理，因此可以利用高可用架构，如Sentinel或Cluster，将碎片率过高的主节点转换为从节点，进行安全重启子进程内存消耗主要指执行AOF/RDB重写时Redis创建的子进程内存消耗。Redis执行fork操作产生的子进程内存占用量对外表现为与父进程相同，理论上需要一倍的物理内存来完成重写操作。
内存大页机制(Transport Huge Pages，THP)，是linux2.6.38后支持的功能，该功能支持2MB的大爷内存分配，默认开启。在redis.conf中增加了一个新的配置项“disable-thp”来控制THP是否开启。
子进程内存消耗总结如下：
1、Redis产生的子进程并不需要消耗1倍的父进程内存，实际消耗根据期间写入命令量决定，但是依然要预留出一些内存防止溢出。
2、需要设置sysctl vm.overcommit_memory=1允许内核可以分配所有的物理内存，防止Redis进程执行fork时因系统剩余内存不足而失败。
3、排查当前系统是否支持并开启THP，如果开启建议关闭，防止-onwrite期间内存过度消耗。
在日志信息中可以查看到关于THP的日志内容， 如下：
Redis使用maxmemory参数限制最大可用内存。限制内存的目的主要有：
1、用于缓存场景，当超出内存上限maxmemory时使用LRU等删除策略释放空间。
2、防止所用内存超过服务器物理内存。
需要注意 ，maxmemory限制的是Redis实际使用的内存量，也就是used_memory统计项对应的内存。由于内存碎片率的存在，实际消耗的内存可能会比maxmemory设置的更大，实际使用时要小心这部分内存溢出。
Redis的内存回收机制主要体现在以下两个方面：
1、删除到达过期时间的键对象。
2、内存使用达到maxmemory上限时触发内存溢出控制策略。
删除过期键对象：
Redis所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存大量的键，维护每个键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。
● 惰性删除：惰性删除用于当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空，这种策略是出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除。但是单独用这种方式存在内存泄露的问题，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。正因为如此，Redis还提供另一种定时任务删除机制作为惰性删除的补充。
● 定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次(通过配置hz控制)。定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例、使用快慢两种速率模式回收键， 流程如图所示。
当Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略。具体策略受maxmemory-policy参数控制，Redis支持6种策略， 如下所示：
1)noeviction： 默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息(error)OOM command not allowed when used memory，此时Redis只响应读操作。
2)volatile-lru： 根据LRU算法删除设置了超时属性(expire)的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
3)allkeys-lru： 根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
4)allkeys-random： 随机删除所有键，直到腾出足够空间为止。
5)volatile-random： 随机删除过期键，直到腾出足够空间为止。
6)volatile-ttl： 根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
‘陆’ Redis是将数据储存进内存吗
Redis就是基于内存可持久化的key-value数据库。
性能问题，Hashmap存储大量数据时需要不断扩容，Redis支持2的32次方个key，每个key或者value大小最大512M；
Hashmap是线程不安全的，redis因为操作原子性不需要考虑这个；
Redis可持久化，Hashmap虽然也可以序列化，但是Java的序列化因为安全问题说是要废除了，效率也没有Redis高，而且Redis有多种持久化策略；
Redis可扩展可分布式部署
‘柒’ Redis的内存优化
一. redisObject对象
二. 缩减键值对象
三. 共享对象池
四. 字符串优化
五. 编码优化
六. 控制key的数量
Redis存储的所有值对象在内部定义为redisObject结构体，内部结构如下图所示。
表示当前对象使用的数据类型，Redis主要支持5种数据类型:string,hash,list,set,zset。可以使用type {key}命令查看对象所属类型，type命令返回的是值对象类型，键都是string类型。
表示Redis内部编码类型，encoding在Redis内部使用，代表当前对象内部采用哪种数据结构实现。理解Redis内部编码方式对于优化内存非常重要 ，同一个对象采用不同的编码实现内存占用存在明显差异，具体细节见之后编码优化部分。
记录对象最后一次被访问的时间，当配置了 maxmemory和maxmemory-policy=volatile-lru | allkeys-lru 时， 用于辅助LRU算法删除键数据。可以使用object idletime {key}命令在不更新lru字段情况下查看当前键的空闲时间。
记录当前对象被引用的次数，用于通过引用次数回收内存，当refcount=0时，可以安全回收当前对象空间。使用object refcount {key}获取当前对象引用。当对象为整数且范围在[0-9999]时，Redis可以使用共享对象的方式来节省内存。具体细节见之后共享对象池部分。
与对象的数据内容相关，如果是整数直接存储数据，否则表示指向数据的指针。Redis在3.0之后对值对象是字符串且长度<=39字节的数据，内部编码为embstr类型，字符串sds和redisObject一起分配，从而只要一次内存操作。
降低Redis内存使用最直接的方式就是缩减键（key）和值（value）的长度。
其中java-built-in-serializer表示JAVA内置序列化方式，更多数据见jvm-serializers项目: https://github.com/eishay/jvm-serializers/wiki，其它语言也有各自对应的高效序列化工具。
值对象除了存储二进制数据之外，通常还会使用通用格式存储数据比如:json，xml等作为字符串存储在Redis中。这种方式优点是方便调试和跨语言，但是同样的数据相比字节数组所需的空间更大，在内存紧张的情况下，可以使用通用压缩算法压缩json,xml后再存入Redis，从而降低内存占用，例如使用GZIP压缩后的json可降低约60%的空间。
对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。
整数对象池在Redis中通过变量REDIS_SHARED_INTEGERS定义，不能通过配置修改。可以通过object refcount 命令查看对象引用数验证是否启用整数对象池技术，如下:
设置键foo等于100时，直接使用共享池内整数对象，因此引用数是2，再设置键bar等于100时，引用数又变为3，如下图所示。
使用整数对象池究竟能降低多少内存？让我们通过测试来对比对象池的内存优化效果，如下表所示。
使用共享对象池后，相同的数据内存使用降低30%以上。可见当数据大量使用[0-9999]的整数时，共享对象池可以节约大量内存。需要注意的是对象池并不是只要存储[0-9999]的整数就可以工作。当设置maxmemory并启用LRU相关淘汰策略如:volatile-lru，allkeys-lru时，Redis禁止使用共享对象池，测试命令如下：
LRU算法需要获取对象最后被访问时间，以便淘汰最长未访问数据，每个对象最后访问时间存储在redisObject对象的lru字段。对象共享意味着多个引用共享同一个redisObject，这时lru字段也会被共享，导致无法获取每个对象的最后访问时间。如果没有设置maxmemory，直到内存被用尽Redis也不会触发内存回收，所以共享对象池可以正常工作。
综上所述，共享对象池与maxmemory+LRU策略冲突，使用时需要注意。 对于ziplist编码的值对象，即使内部数据为整数也无法使用共享对象池，因为ziplist使用压缩且内存连续的结构，对象共享判断成本过高，ziplist编码细节后面内容详细说明。
首先整数对象池复用的几率最大，其次对象共享的一个关键操作就是判断相等性，Redis之所以只有整数对象池，是因为整数比较算法时间复杂度为O(1)，只保留一万个整数为了防止对象池浪费。如果是字符串判断相等性，时间复杂度变为O(n)，特别是长字符串更消耗性能(浮点数在Redis内部使用字符串存储)。对于更复杂的数据结构如hash,list等，相等性判断需要O(n2)。对于单线程的Redis来说，这样的开销显然不合理，因此Redis只保留整数共享对象池。
字符串对象是Redis内部最常用的数据类型。所有的键都是字符串类型， 值对象数据除了整数之外都使用字符串存储。比如执行命令:lpush cache:type “redis” “memcache” “tair” “levelDB” ，Redis首先创建”cache:type”键字符串，然后创建链表对象，链表对象内再包含四个字符串对象，排除Redis内部用到的字符串对象之外至少创建5个字符串对象。可见字符串对象在Redis内部使用非常广泛，因此深刻理解Redis字符串对于内存优化非常有帮助:
Redis没有采用原生C语言的字符串类型而是自己实现了字符串结构，内部简单动态字符串(simple dynamic string)，简称SDS。结构下图所示。
Redis自身实现的字符串结构有如下特点:
因为字符串(SDS)存在预分配机制，日常开发中要小心预分配带来的内存浪费，例如下表的测试用例。
从测试数据可以看出，同样的数据追加后内存消耗非常严重，下面我们结合图来分析这一现象。阶段1每个字符串对象空间占用如下图所示。
阶段1插入新的字符串后，free字段保留空间为0，总占用空间=实际占用空间+1字节，最后1字节保存‘\0’标示结尾，这里忽略int类型len和free字段消耗的8字节。在阶段1原有字符串上追加60字节数据空间占用如下图所示。
追加操作后字符串对象预分配了一倍容量作为预留空间，而且大量追加操作需要内存重新分配，造成内存碎片率(mem_fragmentation_ratio)上升。直接插入与阶段2相同数据的空间占用，如下图所示。
阶段3直接插入同等数据后，相比阶段2节省了每个字符串对象预分配的空间，同时降低了碎片率。
字符串之所以采用预分配的方式是防止修改操作需要不断重分配内存和字节数据拷贝。但同样也会造成内存的浪费。字符串预分配每次并不都是翻倍扩容，空间预分配规则如下:
字符串重构:指不一定把每份数据作为字符串整体存储，像json这样的数据可以使用hash结构，使用二级结构存储也能帮我们节省内存。同时可以使用hmget,hmset命令支持字段的部分读取修改，而不用每次整体存取。例如下面的json数据：
分别使用字符串和hash结构测试内存表现，如下表所示。
根据测试结构，第一次默认配置下使用hash类型，内存消耗不但没有降低反而比字符串存储多出2倍，而调整hash-max-ziplist-value=66之后内存降低为535.60M。因为json的videoAlbumPic属性长度是65，而hash-max-ziplist-value默认值是64，Redis采用hashtable编码方式，反而消耗了大量内存。调整配置后hash类型内部编码方式变为ziplist，相比字符串更省内存且支持属性的部分操作。下一节将具体介绍ziplist编码优化细节。
Redis对外提供了string,list,hash,set,zet等类型，但是Redis内部针对不同类型存在编码的概念，所谓编码就是具体使用哪种底层数据结构来实现。编码不同将直接影响数据的内存占用和读写效率。使用object encoding {key}命令获取编码类型。如下:
Redis针对每种数据类型(type)可以采用至少两种编码方式来实现，下表表示type和encoding的对应关系。
了解编码和类型对应关系之后，我们不禁疑惑Redis为什么需要对一种数据结构实现多种编码方式？
主要原因是Redis作者想通过不同编码实现效率和空间的平衡。比如当我们的存储只有10个元素的列表，当使用双向链表数据结构时，必然需要维护大量的内部字段如每个元素需要:前置指针，后置指针，数据指针等，造成空间浪费，如果采用连续内存结构的压缩列表(ziplist)，将会节省大量内存，而由于数据长度较小，存取操作时间复杂度即使为O(n2)性能也可满足需求。
Redis内存优化
编码类型转换在Redis写入数据时自动完成，这个转换过程是不可逆的，转换规则只能从小内存编码向大内存编码转换。例如：
以上命令体现了list类型编码的转换过程，其中Redis之所以不支持编码回退，主要是数据增删频繁时，数据向压缩编码转换非常消耗CPU，得不偿失。以上示例用到了list-max-ziplist-entries参数，这个参数用来决定列表长度在多少范围内使用ziplist编码。当然还有其它参数控制各种数据类型的编码，如下表所示：
掌握编码转换机制，对我们通过编码来优化内存使用非常有帮助。下面以hash类型为例，介绍编码转换的运行流程，如下图所示。
理解编码转换流程和相关配置之后，可以使用config set命令设置编码相关参数来满足使用压缩编码的条件。对于已经采用非压缩编码类型的数据如hashtable,linkedlist等，设置参数后即使数据满足压缩编码条件，Redis也不会做转换，需要重启Redis重新加载数据才能完成转换。
ziplist编码主要目的是为了节约内存，因此所有数据都是采用线性连续的内存结构。ziplist编码是应用范围最广的一种，可以分别作为hash、list、zset类型的底层数据结构实现。首先从ziplist编码结构开始分析，它的内部结构类似这样:<….>。一个ziplist可以包含多个entry(元素)，每个entry保存具体的数据(整数或者字节数组)，内部结构如下图所示。
ziplist结构字段含义：
根据以上对ziplist字段说明，可以分析出该数据结构特点如下:
下面通过测试展示ziplist编码在不同类型中内存和速度的表现，如下表所示。
测试数据采用100W个36字节数据，划分为1000个键，每个类型长度统一为1000。从测试结果可以看出：
intset编码是集合(set)类型编码的一种，内部表现为存储有序，不重复的整数集。当集合只包含整数且长度不超过set-max-intset-entries配置时被启用。执行以下命令查看intset表现：
以上命令可以看出intset对写入整数进行排序，通过O(log(n))时间复杂度实现查找和去重操作，intset编码结构如下图所示。
intset的字段结构含义：
根据以上测试结果发现intset表现非常好，同样的数据内存占用只有不到hashtable编码的十分之一。intset数据结构插入命令复杂度为O(n)，查询命令为O(log(n))，由于整数占用空间非常小，所以在集合长度可控的基础上，写入命令执行速度也会非常快，因此当使用整数集合时尽量使用intset编码。上表测试第三行把ziplist-hash类型也放入其中，主要因为intset编码必须存储整数，当集合内保存非整数数据时，无法使用intset实现内存优化。这时可以使用ziplist-hash类型对象模拟集合类型，hash的field当作集合中的元素，value设置为1字节占位符即可。使用ziplist编码的hash类型依然比使用hashtable编码的集合节省大量内存。
当使用Redis存储大量数据时，通常会存在大量键，过多的键同样会消耗大量内存。Redis本质是一个数据结构服务器，它为我们提供多种数据结构，如hash，list，set，zset 等结构。使用Redis时不要进入一个误区，大量使用get/set这样的API，把Redis当成Memcached使用。对于存储相同的数据内容利用Redis的数据结构降低外层键的数量，也可以节省大量内存。如下图所示，通过在客户端预估键规模，把大量键分组映射到多个hash结构中降低键的数量。
hash结构降低键数量分析：
通过这个测试数据，可以说明：
关于hash键和field键的设计：
使用hash结构控制键的规模虽然可以大幅降低内存，但同样会带来问题，需要提前做好规避处理。如下:
本文主要讲解Redis内存优化技巧，Redis的数据特性是”ALL IN MEMORY”，优化内存将变得非常重要。对于内存优化建议读者先要掌握Redis内存存储的特性比如字符串，压缩编码，整数集合等，再根据数据规模和所用命令需求去调整，从而达到空间和效率的最佳平衡。建议使用Redis存储大量数据时，把内存优化环节加入到前期设计阶段，否则数据大幅增长后，开发人员需要面对重新优化内存所带来开发和数据迁移的双重成本。当Redis内存不足时，首先考虑的问题不是加机器做水平扩展，应该先尝试做内存优化。当遇到瓶颈时，再去考虑水平扩展。即使对于集群化方案，垂直层面优化也同样重要，避免不必要的资源浪费和集群化后的管理成本。
‘捌’ redis内存满了怎么办
redis内存满了解决方法：
1，增加内存。
2，使用内存淘汰策略。
3，Redis集群。
重点介绍下2、3：
第二点：
我们知道，redis设置配置文件的maxmemory参数，可以控制其最大可用内存大小（字节）。
那么当所需内存，超过maxmemory怎么办？
这个时候就该配置文件中的maxmemory-policy出场了。
其默认值是noeviction。
下面我将列出当可用内存不足时，删除redis键具有的淘汰规则。
规则说明：
1、volatile-lru
使用LRU算法删除一个键（只对设置了生存时间的键）
2、allkeys-lru
使用LRU算法删除一个键
3、volatile-random
随机删除一个键（只对设置了生存时间的键）
4、allkeys-random
随机删除一个键
5、volatile-ttl
删除生存时间最近的一个键
6、noeviction
不删除键，只返回错误
LRU算法，least RecentlyUsed，最近最少使用算法。也就是说默认删除最近最少使用的键。
但是一定要注意一点！redis中并不会准确的删除所有键中最近最少使用的键，而是随机抽取3个键，删除这三个键中最近最少使用的键。
那么3这个数字也是可以设置的，对应位置是配置文件中的maxmeory-samples.
三、集群怎么做
Redis仅支持单实例，内存一般最多10~20GB。对于内存动辄100~200GB的系统，就需要通过集群来支持了。
Redis集群有三种方式：客户端分片、代理分片、RedisCluster(在之后一篇文章详细说一下。)
1、客户端分片
通过业务代码自己实现路由
优势：可以自己控制分片算法、性能比代理的好
劣势：维护成本高、扩容/缩容等运维操作都需要自己研发
2、代理分片
代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。使用类似Twemproxy、Codis等中间件实现。
优势：运维方便、程序不用关心如何链接Redis实例
劣势：会带来性能消耗（大概20%）、无法平滑扩容/缩容，需要执行脚本迁移数据，不方便(Codis在Twemproxy基础上优化并实现了预分片来达到Auto Rebalance)。
3、Redis Cluster
优势：官方集群解决方案、无中心节点，和客户端直连，性能较好
劣势：方案太重、无法平滑扩容/缩容，需要执行相应的脚本，不方便、太新，没有相应成熟的解决案例
‘玖’ Redis的主要功能
缓存：这应该是 Redis 最主要的功能了，也是大型网站必备机制，合理地使用缓存不仅可以加 快数据的访问速度，而且能够有效地降低后端数据源的压力。共享Session：对于一些依赖 session 功能的服务来说，如果需要从单机变成集群的话，可以选择 redis 来统一管理 session。消息队列系统：消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务 解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功 能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功 能基本可以满足。比如在分布式爬虫系统中，使用 redis 来统一管理 url队列。分布式锁：在分布式服务中。可以利用Redis的setnx功能来编写分布式的锁，虽然这个可能不是太常用。 当然还有诸如排行榜、点赞功能都可以使用 Redis 来实现，但是 Redis 也不是什么都可以做，比如数据量特别大时，不适合 Redis，我们知道 Redis 是基于内存的，虽然内存很便宜，但是如果你每天的数据量特别大，比如几亿条的用户行为日志数据，用 Redis 来存储的话，成本相当的高。
‘拾’ Redis内存满了会怎么样
1、通过配置文件配置
通过在Redis安装目录下面的redis.conf配置文件中添加以下配置设置内存大小
redis的配置文件不一定使用的是安装目录下面的redis.conf文件，启动redis服务的时候是可以传一个参数指定redis的配置文件的
2、通过命令修改
Redis支持运行时通过命令动态修改内存大小
既然可以设置Redis最大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往Redis里面添加数据不就没内存可用了吗？
实际上Redis定义了几种策略用来处理这种情况：
当使用volatile-lru、volatile-random、volatile-ttl这三种策略时，如果没有key可以被淘汰，则和noeviction一样返回错误
获取当前内存淘汰策略：
通过配置文件设置淘汰策略（修改redis.conf文件）：
通过命令修改淘汰策略：
近似LRU算法
Redis使用的是近似LRU算法，它跟常规的LRU算法还不太一样。近似LRU算法通过随机采样法淘汰数据，每次随机出5（默认）个key，从里面淘汰掉最近最少使用的key。
可以通过maxmemory-samples参数修改采样数量：
例：maxmemory-samples 10
maxmenory-samples配置的越大，淘汰的结果越接近于严格的LRU算法
Redis为了实现近似LRU算法，给每个key增加了一个额外增加了一个24bit的字段，用来存储该key最后一次被访问的时间。
Redis3.0对近似LRU的优化
Redis3.0对近似LRU算法进行了一些优化。新算法会维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中最小的时间才会放入池中，直到候选池被放满。当放满后，如果有新的key需要放入，则将池中最后访问时间最大（最近被访问）的移除。
当需要淘汰的时候，则直接从池中选取最近访问时间最小（最久没被访问）的key淘汰掉就行。