redis避坑

最新推荐文章于 2024-05-05 16:28:17 发布

打分几楼MOTO

最新推荐文章于 2024-05-05 16:28:17 发布

阅读量1.9k

点赞数

分类专栏： Redis 文章标签： redis

本文链接：https://blog.csdn.net/qq_44447372/article/details/124088251

版权

Redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

正确的选择数据类型

都使用string去存储数据存在哪些弊端

浪费存储空间,key也是需要存储空间的
管理维护麻烦,Redis中存在着大量的KV对象
key冲突比较高
建议使用hash存储对象

命名策略

业务名称+工程名+模块名+(有意义的)键名

常用的数据类型及其适用场景

string
- 应用最广泛的数据类型,例如计数器,session等键值"独立"的数据
hash
- 存储结构化(对象)的数据,KV共同构成一个对象的信息
list
- 队列,栈,有界队列
set
- 去重,无序的数据集合,在类似于社交的业务功能上有广泛应用,例如:共同关注,共同喜好,数据去重
sortedset
- 带有权重的集合,在类似于排行榜业务上有广泛应用,且可以视线范围查找

用了事务却没有发生回滚

redis事务

redis事务的两类错误

为什么redis不支持回滚

失败的命令是因为编程错误造成的,这些错误应该在开发的过程中被发现,所以不支持回滚
如果检测到了事务命令的错误应该不加思索的使用discard放弃这个事务

redis性能上不去,可能是有 big key

big key以及造成的危害

数据量大的key,比如字符串的Value值非常大( > 10kB),哈希,列表,集合,有序集合元素多(元素个数>5000)
big key造成的危害
- 内存不均:针对redis集群来说,不确定存在集群的哪一台机器上,或造成不同的机器使用内存不均的情况
- 超时阻塞,redis操作big key比较耗时,阻塞redis的可能性就会变得很大
- 网络流量阻塞,每次获取要产生的网络流量比较大
- 过期删除,过期删除时间长,可能会阻塞
- 迁移困难:备份和导入都会导致阻塞,迁移困难

big key是如何产生的

社交类场景
- 粉丝列表,对于明星或者大V来说,需要特殊的设计,否则,就成为了BigKey
汇总统计类场景
- 每天都会产生报表数据,报表数据汇总到一个key里面,日积月累就成为了BigKey
日常缓存类场景
- 对DB中的数据进行缓存,大表(存在大字段)很可能会产生BigKey

如何发现BigKey

redis-cli提供了 --bigkeys来查找bigkey:给出了每种数据结构的top 1 bigkey,同时也给出了每种数据类型键值个数以及平均大小
- 如果想查询redis中大于10KB的所有key,--bigkeys就无能为力了

redis4.0开始提供了memory usage命令可以计算每个键值对的字节数(Redis为了保存这个键值对一共需要消耗的内存,包括指针开销)

删除bigkey

Redis怎么出现了内存耗尽

Redis服务器内存耗尽的场景

内存耗尽的结果是只能读而不能写

业务不断发展,缓存数据不断增多,需要消耗Redis内存
无效(过期)的数据没有及时清理,需要消耗Redis内存(优化点)
没有对"冷数据"(不经常访问的用户)进行降级需要消耗Redis内存(优化点:直接从redis中删除,当发送请求时从mysql中直接读然后再写到mysql中);

将key标记为Volatile(易失的)

ttl key 查看过期时间
expire key seconds 给key增加一个过期时间
rename beforekey afterkey 不会改变过期时间
presist key 将这个key过期时间移除,标记为持久的key

Redis的过期删除策略

定时删除
- 为每一个设置了过期时间的key都会创建一个定时器,一旦到达过期时间就会立即删除
惰性删除
- 当访问一个key时,才判断key是否过期,过期删除
定期删除
- 每个一段时间,扫描Redis中过期key字典,并删除部分过期的key
redis使用了定期+惰性删除

有了过期机制以后内存还是不够用

设置了过期Redis服务器内存还是不够用原因

业务缓存数据需求量大,占用大量的内存空间
过期的key虽然有很多,但是不能"及时失效",仍会有大量的key堆积在内存中,导致Redis内存耗尽

有没有办法让Redis主动帮我们淘汰"一些数据"呢??

Redis的内存淘汰策略

Redis的内存淘汰策略,是指内存达到maxmemory极限时,使用某种算法来决定清理掉哪些数据,以保证新数据的写入
最常用的内存淘汰策略
- Volatile:只会针对带过期时间的key进行淘汰
  - volatile-lru:最近最久未被使用的key
  - volatile-random:随机的key
  - volatile-ttl:根据key的剩余时间,越小优先会被淘汰
- allkeys:策略会针对所有的key进行淘汰
  - allkeys-lru:最近最久未被使用的key
  - allkeys-random:随机的key
- noeviction:默认的淘汰策略,当redis满了之后就不能提供写服务,但是可以提供读服务
内存淘汰策略的执行时机:Redis会在每一次处理命令的时候判断当前是否已经达到了内存的最大限制,如果达到限制,则使用对应的算法去处理需要删除的key
- 配置Redis:redis.conf maxmemory 10240000 maxmemory-policy noviction
如何选择??
- 如果拿redis做缓存,那应该使用allkeys下的淘汰策略
- 如果你还想同时使用redis的持久化功能,那就是用volatile下的淘汰策略

如何解决频繁的命令往返造成的性能瓶颈

redis客户端和服务端的交互模型

redis是基于一个request,一个response的同步请求服务
数据包往返于两端的时间被称为RTT

redis的pipeline的交互模型

减少客户端与服务端通信的次数
pipeline是基于队列实现的,保证了先进先出

调用redisTemplate.executePilelined方法.重写里面的RedisCallback<Object>里面的doInRedis方法,在该方法里面首选需要根据参数connection打开pipeline(connection.openPipeline),通过connection添加我们的命令.注意:不能关闭Pipeline,不然到最后我们得不到返回值,需要返回null