re di s 内存玩的是真的6 哦

132 阅读3分钟

「这是我参与2022首次更文挑战的第37天,活动详情查看:2022首次更文挑战」

内存分配

  • maxmemory 指定大小。在redis.conf配置文件中可以直接指定。他的单位时byte。

image-20210617144838455

  • 上图中注释部分是给大家的解释,实际中#配置需要换行哈!!!友情提示
  • 另外我们可以连接上redis通过config命令来设置

image-20210617145851812

  • 两种方式都可以设置,前者是全局设置重启之后仍然有效!后者是临时设置重启之后就会重新加载redis.conf中的配置。

键过期

  • 上面我们从redis本身角度出发设置了内存限制,这样不用担心他们吞噬系统内存!下面就需要我们开发者设计角度约束自己了。

设置过期时间

expire key time
  • 设置过期时间默认单位时S 。

  • 然后通过ttl 命令可以查看剩余过期时间

image-20210617151445320

  • 经过多次执行ttl能够观察到剩余时间在不断的减少!当减少到0的时候就被给驱逐策略驱逐!注意这里说的是驱逐策略驱逐并不是意味着立马被删除

更新过期时间

  • del key 直接将key删除了那么该key对应的过期自然也就不存在了!这种情况笔者也算作是更新过期时间
  • set getset等命令重新设置key、value方式会覆盖过期时间 , 直接被覆盖成-1

image-20210617152121178

  • setgetset包括del严格意义是覆盖过期时间。真正做到更新过期时间的还是expire .在expire是已最新为准的!
  • 上面其实都修改了key才会应发原本的过期时间失效的!因为此key非彼key 。 但是appendincr 等命令是改变值这种命令是不会影响到原来的过期设置的

淘汰策略

  • 根据上面配置我们可以将我们的redis最大内存设置为1MB , 设置大小随便最好能小点。然后我们通过Java小程序不断向redis中填充。最终当内存不够使用时就会报错

  • 报错就是因为内存满了,新增的key被redis拒绝了!不仅仅是新增的被拒绝,就算此时我们想改变已经在redis中的key的值也是不可用的

  • 不管是append 还是set 都是报OOM command not allowed when used memory > maxmemory 。代码中打印和redis键个数一致;说明我们默认的淘汰策略是直接拒绝

  • 总结下来就是:当redis内存被使用满了后,任何的写操作都会被拒绝!

  • 当没有足够内存时难道就这么直接拒绝吗?上面也提到了需要我们程序员自己根据需求设置键过期已释放内存供其他有需要的key使用!那么设置了过期key之后这些key又是怎么被清除的呢? 这就牵扯出我们的淘汰策略

image-20210617163430236