redis默认内存占物理内存多少

‘壹’ redis maxmemory默认值是多少

# Redis 配置文件

# 当配置中需芦液要配置内存大小时，可以使用 1k, 5GB, 4M 等类似的格式，其转换方式如下(不区分大小写)
#
# 1k =>
1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb =>
1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024
bytes
#
# 内存配置大小逗哗轮写是一样的.比如 1gb 1Gb 1GB 1gB

# daemonize no 默认情况下，redis不是山信在后台运行的，如果需要在后台运行，把该项的值更改为yes
daemonize
转载，仅供参考。

‘贰’ redis这些内存消耗数据怎么看呢，主要看哪个说明内存比较大了

Redis常用数据类型
Redis最为常用的数据类型主要有以下五种：
String
Hash
List
Set
Sorted set
在具体描述这几种数据类型之前，我们先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的：
首先Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示：type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如：“123” “456”这样的字符串。
这里需要特殊说明一下vm字段，只有打开了Redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的，该功能会在后面具体描述。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。
下面我们先来逐一的分析下这五种数据类型的使用和内部实现方式：
String
常用命令：
set,get,decr,incr,mget 等。
应用场景：
String是最常用的一种数据类型，普通的key/value存储都可以归为此类，这里就不所做解释了。
实现方式：
String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
Hash
常用命令：
hget,hset,hgetall 等。
应用场景：
我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：
常用内存优化手段与参数
通过我们上面的一些实现上的分析可以看出redis实际上的内存管理成本非常高，即占用了过多的内存，作者对这点也非常清楚，所以提供了一系列的参数和手段来控制和节省内存，我们分别来讨论下。
首先最重要的一点是不要开启Redis的VM选项，即虚拟内存功能，这个本来是作为Redis存储超出物理内存数据的一种数据在内存与磁盘换入换出的一个持久化策略，但是其内存管理成本也非常的高，并且我们后续会分首辩析此种持久化策略并不成熟，所以要关闭VM功能，请检查你的redis.conf文件中 vm-enabled 为 no。
其次最好设置下redis.conf中的maxmemory选项，该选项是告诉Redis当使用了多少物理内存后就开始拒绝后续的写入请求，该参数能很好的保行简护好你的Redis不会因为使用了过多的物理内存而导致swap,最终严重影响性能甚至崩溃。
另外Redis为不同数据类型分别提供了一组参数来控制内存使用，我们在前面档芹裤详细分析过Redis Hash是value内部为一个HashMap，如果该Map的成员数比较少，则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销，这个参数控制对应在redis.conf配置文件中下面2项：
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
hash-max-zipmap-entries
含义是当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储，默认是64,即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的HashMap。
hash-max-zipmap-value 含义是当 value这个Map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。
以上2个条件任意一个条件超过设置值都会转换成真正的HashMap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，HashMap的优势就是查找和操作的时间复杂度都是O（1）的，而放弃Hash采用一维存储则是O（n）的时间复杂度，如果
成员数量很少，则影响不大，否则会严重影响性能，所以要权衡好这个值的设置，总体上还是最根本的时间成本和空间成本上的权衡。
同样类似的参数还有：
list-max-ziplist-entries 512
说明：list数据类型多少节点以下会采用去指针的紧凑存储格式。
list-max-ziplist-value 64
说明：list数据类型节点值大小小于多少字节会采用紧凑存储格式。
set-max-intset-entries 512
说明：set数据类型内部数据如果全部是数值型，且包含多少节点以下会采用紧凑格式存储。
最后想说的是Redis内部实现没有对内存分配方面做过多的优化，在一定程度上会存在内存碎片，不过大多数情况下这个不会成为Redis的性能瓶颈，不过如果在Redis内部存储的大部分数据是数值型的话，Redis内部采用了一个shared integer的方式来省去分配内存的开销，即在系统启动时先分配一个从1~n 那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下，也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义REDIS_SHARED_INTEGERS，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。
Redis的持久化机制
Redis由于支持非常丰富的内存数据结构类型，如何把这些复杂的内存组织方式持久化到磁盘上是一个难题，所以Redis的持久化方式与传统数据库的方式有比较多的差别，Redis一共支持四种持久化方式，分别是：
在设计思路上，前两种是基于全部数据都在内存中，即小数据量下提供磁盘落地功能，而后两种方式则是作者在尝试存储数据超过物理内存时，即大数据量的数据存储，截止到本文，后两种持久化方式仍然是在实验阶段，并且vm方式基本已经被作者放弃，所以实际能在生产环境用的只有前两种，换句话说Redis目前还只能作为小数据量存储（全部数据能够加载在内存中），海量数据存储方面并不是Redis所擅长的领域。下面分别介绍下这几种持久化方式：
定时快照方式（snapshot）：
该持久化方式实际是在Redis内部一个定时器事件，每隔固定时间去检查当前数据发生的改变次数与时间是否满足配置的持久化触发的条件，如果满足则通过操作系统fork调用来创建出一个子进程，这个子进程默认会与父进程共享相同的地址空间，这时就可以通过子进程来遍历整个内存来进行存储操作，而主进程则仍然可以提供服务，当有写入时由操作系统按照内存页（page）为单位来进行-on-write保证父子进程之间不会互相影响。
该持久化的主要缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。
基于语句追加方式（aof）：
aof方式实际类似mysql的基于语句的binlog方式，即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是Redis的持久化数据。
aof的方式的主要缺点是追加log文件可能导致体积过大，当系统重启恢复数据时如果是aof的方式则加载数据会非常慢，几十G的数据可能需要几小时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写log,所以使用aof的方式，Redis的读写性能也会有所下降。
虚拟内存方式：
虚拟内存方式是Redis来进行用户空间的数据换入换出的一个策略，此种方式在实现的效果上比较差，主要问题是代码复杂，重启慢，复制慢等等，目前已经被作者放弃。
diskstore方式：
diskstore方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的B-tree的方式，目前仍在实验阶段，后续是否可用我们可以拭目以待。
Redis持久化磁盘IO方式及其带来的问题
有Redis线上运维经验的人会发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork 调用的-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般你的系统不会在短时间内所有的页都发生了写入而导致复制，那么是什么原因导致Redis崩溃的呢？
答案是Redis的持久化使用了Buffer IO造成的，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache,而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大（尤其是快照文件），并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层Cache,而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做Page Cache的剔除工作，但内核很可能认为某块Page Cache更重要，而让你的进程开始Swap ,这时你的系统就会开始出现不稳定或者崩溃了。我们的经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。
定时快照方式（snapshot）
基于语句追加文件的方式（aof）
虚拟内存（vm）
Diskstore方式
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口，如下图：
也就是说，Key仍然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部Map的Key（Redis里称内部Map的key为field）， 也就是通过 key（用户ID） + field（属性标签） 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。
这里同时需要注意，Redis提供了接口（hgetall）可以直接取到全部的属性数据，但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
实现方式：
上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
List
常用命令：
lpush,rpush,lpop,rpop,lrange等。
应用场景：
Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现，比较好理解，这里不再重复。
实现方式：
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
Set
常用命令：
sadd,spop,smembers,sunion 等。
应用场景：
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
实现方式：
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
Sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用场景：
Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级（score）的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：
Redis sorted set的内部使用HashMap和跳跃表（SkipList）来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

‘叁’ Redis的各数据类型的内存占用

先给一个Redis分析内存占用的网址： http://www.redis.cn/redis_memory/
这个工具会给我们一个内存占用分析，示例如下图：

我们在使用Redis的时候，String 类型是我们使仿李用最多的，他也是唯一的一个非集合类型。
然而String类型并不是适用于所有场合的，它有一个明显的短板，就是它保存数据时所消耗的内存空间较多。
为什么String类型的占用的空间比较大呢，那是因为他除了记录实际数据，String 类型还需要额外的内存空间记录数据长度、空间使用等信息，这些信息也叫作元数据。当实际保存的数据较小时，元数据的空间开销就显得比较大了。

当你保存 64 位有符号整数时，String 类型会把它保存为一个 8 字节的 Long 类型整数，这种保存方式通常也叫作 int 编码方式。但是，当你保存的数据中包含字符时，String 类型就会用简单动态字符串（Simple Dynamic String，SDS）结构体来保存。
其中SDS的保存占用的内存如下所示：

在 SDS 中，buf 保存实际数据，而 len 和 alloc 本身其实是 SDS 结构体的额外开销。
然而，除了SDS的额外开销，String类型还有一个RedisObject 结构体（包备银迟含了八个字节的元数据和八个字节的指针）的开销，如下图所示：

为了解决上面提到的String类型占用内存过多的情况，我们可以使用压缩表来存储。
压缩列表之所以能节省内存，就在于它是用一系列连续的 entry 保存数据。

Redis 基于压缩列表实现了 List、Hash 和 Sorted Set 这样的集合类型，这样做的最大好处就是节省了 dictEntry 的开销。当你用 String 类型时，一个键值对就有一个 dictEntry，要用 32 字节空间。但采用集合类型时，一个 key 就对应一个集合的数据，能保存的数据多了很多，但也只用了一个 dictEntry，这样就节省了搏培内存。
Hash 类型设置了用压缩列表保存数据时的两个阈值，一旦超过了阈值，Hash 类型就会用哈希表来保存数据了。这两个阈值分别对应以下两个配置项：
hash-max-ziplist-entries：表示用压缩列表保存时哈希集合中的最大元素个数。
hash-max-ziplist-value：表示用压缩列表保存时哈希集合中单个元素的最大长度。

‘肆’ redis 一个数据库能存多少数据

redis一个实例能存一个key或是value大小最大是512M。操作方法如下：

1、首先要安装redis，开启redis的服务。掘世败

‘伍’ Redis内存配置和淘汰策略

1.在redis安装目录下找到redis.conf，打开找到如下行：

其中的maxmemory <bytes>即为最大内存配置项，默认是注释掉的会采用 默认的最大内存大小 ：在64位操作系统下不限制内存大小，在32位操作系统下最多使用3GB。

2.在客户端通过命令行查看

这里结果为0表示未手动指定过最大内存，采用默认的最大内存。

一般推荐Redis设置内存为最大物理内存的四分之三。

1.在配置文件redis.conf中指定maxmemory参数，例如，如果最大内存是200M，则在配置文件中添加 maxmemory 209751200 ；
2.通过命令 config set maxmemory 209751200 设置，注意，这里如果是通过命令行设置的最大内存大小，在配置文件redis.conf中并不会添加 maxmemory 209751200 这一行内容。

当Redis达到最大的可用内存时，再向其中存入数据则会报OOM，因此，要避免无限制存入数据导致OOM，则需要采用合适的内存淘汰策略。

在讨论Redis的内存淘汰策略之前，我们要先对Redis中过期键的删除机制有个大体的了解；实际上，过期键的删除策略有三种，每种策略下过期键的删除时机均不同。
1. 定时删除
所谓定时删除，就是在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即删除对键的删除操作。其能够对过期键进行立即删除，对内存是友好的，但是因为要维护定时器，对cpu是不友好的。
2. 惰性删除
所谓惰性删除，就是放任过期键不管，但每次获取键时，都检查取得的键是否过期，如果过期的汪游话，就删除该键。如果没有过期，就返回该键。惰性删除对cpu友好，但是由于其无法主动删除过期键，当过期键大量积聚时会占用很大内存，对内存不友好。
3. 定期删除
所谓定期删除，是前两种删除策略的一种折中。会每隔一段时间执行一次删除过期键操作，并通过限制操作执行的时长和频率来减少删除操作对cpu时间的影响。
定期删除会周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度，其特点为：
a）CPU占用设置有峰值，检测频度可自定义设置。
b）内存压力有限，长期占用内存的冷数据会被持续清理。
总结下来，定期删除会周期性抽查存储空间（随机抽查、重点抽查）。
定期删除的难点在于如何确定产出操作执行的时长和频率，如果删除操作执行的太过频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多的消耗在删除键上面。如果删除操作执行的太少，或者执行的时间太短，定期删除策略又会和惰性删除策困返销略一样，出现内存浪费的情况。因此，必须合理的设置定期删除策略的执行时长和执行频率。
定期删除在一定程度上是一种合理有效的过期键删除策略，但是由于其在执行时长和执行频度的局限性，必须要有另一种机制（策略）确保内存能够获得回收，因此，就需要引入内存淘汰策略。

在redis.conf中指出内存淘汰策略有有以下八种：
1. volatile-lru ：从已设置过期时间的key中挑选最近最少使用的数据淘汰；
2. allkeys-lru ：从全部key中挑选最近最少使用的数据淘汰；
3. volatile-lfu ：从已设置过期时间的key中世咐挑选使用频率最低的数据淘汰；
4. allkeys-lfu ：从全部key中挑选使用频率最低的数据淘汰；
5. volatile-random ：从已设置过期时间的key中任意选择数据淘汰；
6. allkeys-random ：从全部key中任意选择数据淘汰
7. volatile-ttl ：从已设置过期时间的key中挑选将要过期的数据淘汰；
8. no-enviction ：禁止驱逐数据，这也是默认策略。当内存不足以容纳新入数据时，新写入操作就会报错。

内存淘汰策略的设置与查看

‘陆’ 为什么从redis中取数据比较慢

redis并不会因为key的增加而导致写入明显变慢，肯定是其他因素。
如果redis开启了持久化，在进行持久化时，性能必然下降，可以使带春用config命令查看持久化设置了没有。另外考虑是否是内存不足，一般redis最多只应该占用60%的物理内存，如果超过了在rdb进行持久化携昌时可能会内存不足。可辩行扒以监视内存和cpu使用情况进行分析。

‘柒’ java怎样配置redis占用多大内存

Redis的配置
daemonize 如果需要蔽羡行在后台运行，把该项改为yes
pidfile 配置多个pid的地址，默认在派唯/var/run/redis.pid
bind 绑定ip，设置后只接受自该ip的请求
port 监听端口，默认为6379
timeout 设置客户端连接时的超时时间，单位为秒
loglevel 分为4级，debug、verbose、notice、warning
logfile 配置log文件地址
databases 设置数据库的个数，默认使用的数据库为0
save 设置redis进行数据库镜像的频率，保存快照的频率，第一个*表示多长时间， 第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。
rdbcompression 在进行镜像备份时，是否进行压缩
Dbfilename 镜像备份文件的文件名
Dir 数据库镜像备份的文件放置路径
Slaveof 设置数据库为其他数据库的从数据库
Masterauth 主数据库连接需要的密码验证
Requirepass 设置登录时需要使用的密码
Maxclients 限制同时连接的客户数量
Maxmemory 设置redis能够使用的最大内存
Appendonly 开启append only模式
appendfsync 设置对appendonly.aof文件同步的频率
vm-enabled 是否虚拟内存的支持
vm-swap-file 设置虚拟内存的交换文件路径
vm-max-memory 设置redis使用的最大物理内存大小
vm-page-size 设置虚拟内存的页大小
vm-pages 设置交换文件的总page数量
vm-max-threads 设置VMIO同时使宏哗用的线程数量
glueoutputbuf 把小的输出缓存存放在一起
hash-max-zipmap-entries 设置hash的临界值
activerehashing 重新has