Redis优化总结

# 注意在redis.conf中的小聚合数据类型的特殊编码设置(http://carlosfu.iteye.com/blog/2254572)
```
hash-max-zipmap-entries 64 (hash-max-ziplist-entries for Redis >= 2.6)
hash-max-zipmap-value 512 (hash-max-ziplist-value for Redis >= 2.6)
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512
```
# 使用32位实例将内存受限在4G内,不过他们的RDB和AOF文件是兼容在32位和64位下去切换使用的。

# 使用bit位级别操作和byte字节级别操作来减少不必要的内存使用
>* bit位级别操作:GETRANGE, SETRANGE, GETBIT and SETBIT
>* byte字节级别操作:GETRANGE and SETRANGE

# 尽可能地使用hashes哈希,因为小Hashes会被编码成一个非常小的空间。
# 使用哈希来在Redis的顶部在普通key-value存储上来抽象内存使用效率
# 关于内存分配:
如果maxmemory没有设置的Redis会继续分配内存,因为它认为合适的,因此它可以(逐渐)吃了你的全部可用内存。因此,通常建议配置一些限制。您可能还需要设置maxmemory策略,以noeviction(这不是在一些旧版本的Redis的默认值)。
这使得Redis的返回内存不足的错误写命令,如果当它到达了极限 - 这反过来可能会导致应用程序错误,但不会导致因为内存饥饿而整机死亡。
```
另外redis的6种过期策略,redis中的默认的过期策略是volatile-lru,设置方式
  config set maxmemory-policy volatile-lru
  maxmemory-policy 六种方式
  volatile-lru:只对设置了过期时间的key进行LRU(默认值)
  allkeys-lru : 是从所有key里 删除 不经常使用的key
  volatile-random:随机删除即将过期key
  allkeys-random:随机删除
  volatile-ttl : 删除即将过期的
  noeviction : 永不过期,返回错误
  maxmemory-samples 3 是说每次进行淘汰的时候 会随机抽取3个key 从里面淘汰最不经常使用的(默认选项)
```
# 数据尽量压缩
# 尽量使用短的key
# 使用Hashes值存储而不带额外的数据元

时间: 2024-10-08 04:43:52

Redis优化总结的相关文章

Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

一文带你了解Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

Redis优化经验

内存管理优化 Redis Hash是value内部为一个HashMap,如果该Map的成员数比较少,则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销,这个参数控制对应在redis.conf配置文件中下面2项: hash-max-zipmap-entries 64 hash-max-zipmap-value 512 当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储,默认是64,即value内部有64个以下的成员就是使用线性紧凑存储,超过该值自动转成真正的

redis优化配置和redis.conf说明

1. redis.conf 配置参数: #是否作为守护进程运行 daemonize yes #如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid pidfile redis.pid #绑定主机IP,默认值为127.0.0.1 #bind 127.0.0.1 #Redis默认监听端口 port 6379 #客户端闲置多少秒后,断开连接,默认为300(秒) timeout 300 #日志记录等级,有4个可选值,debug,verbose(默认值),notice,warn

【转载】redis优化

原文链接 批量操作优化: 在使用redis的时候,客户端通过socket向redis服务端发起请求后,等待服务端的返回结果. 客户端请求服务器一次就发送一个报文 -> 等待服务端的返回 -> 关闭连接 如果是100个请求.1000个请求,那就得请求100次.1000次 所以使用多个请求的时候使用管道来操作(如果管道打包的命令太多占用的内存也会越大,适量) 以下是使用3种方式进行的测试(循环写入1000次): public static void main(String[] args) { lo

redis优化

https://blog.csdn.net/crisis_hiding/article/details/81490158 生产环境长时间的运行后,经常会有接口返回数据失败的情况,或者是从监控上发现数据库压力某一时间暴增.查看客户端日志发现这样的错误: redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 从错误日志看,是提示无法获取连接.有两种情况: 1.客户

redis启动时的几个报警错误-redis优化

1)The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128 2)WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcomm

mongodb redis 优化 (centos 7)

mongodb (WARNING: soft rlimits too low) 修改配置文件 /etc/security/limits.conf,添加配置信息: [[email protected] ~]# vi /etc/security/limits.conf mongod soft nofile 64000 mongod hard nofile 64000 mongod soft nproc 32000 mongod hard nproc 32000 mongodb & redis 禁用大

redis优化秒杀系统

用redis提高基于mss的秒杀系统 使用背景: 普通的基于mss框架的系统在并发量不是很高的情况下,对redis的需求不是很高.redis在系统中的角色相当于一个对象缓存器,在高并发的系统中(比如秒杀系统),在某一刻对数据库中的一条数据可能是成千上万的用户同时去访问,系统的用户体验度直接受到数据库的性能的影响.为了保证数据的完整性,用户只能串行访问数据库中的某一条记录.redis则是把记录对应的对象序列化存储在自身的容器中,减少数据库的压力.废话不多说,接下来简单介绍redis的使用. red