redis_内存优化

忆灬凝

已于 2022-03-06 21:32:26 修改

阅读量724

点赞数

CC 4.0 BY-SA版权

分类专栏： redis 文章标签： redis 数据库 database

于 2022-03-06 21:18:41 首次发布

本文链接：https://blog.csdn.net/m0_51800757/article/details/123316368

redis 专栏收录该内容

2 篇文章

订阅专栏

Redis2.2引入位级别和字级别操作，如GETRANGE、SETRANGE等，适用于存储用户标志、节省内存。建议使用散列表（hashes）存储少量内容，当元素增多时自动转为正常散列表。配置maxmemory限制内存使用，防止耗尽所有系统内存。通过内存分配策略优化性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

位级别和字级别的操作

Redis 2.2引入了位级别和字级别的操作: GETRANGE, SETRANGE, GETBIT 和 SETBIT.使用这些命令，你可以把redis的字符串当做一个随机读取的（字节）数组。例如你有一个应用，用来标志用户的ID是连续的整数，你可以使用一个位图标记用户的性别，使用1表示男性，0表示女性，或者其他的方式。这样的话，1亿个用户将仅使用12 M的内存。你可以使用同样的方法，使用 GETRANGE 和 SETRANGE 命令为每个用户存储一个字节的信息。这仅是一个例子，实际上你可以使用这些原始数据类型解决更多问题。

尽可能使用散列表（hashes）

存储的内容很少的散列表能高效利用内存。所以比如你的系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.

当散列表非常小的时候，我们采用将数据encode为一个O(N)的数据结构，你可以认为这是一个带有长度属性的线性数组。只有当N是比较小的时候，才会采用这种encode，这样使用HGET和HSET命令的复杂度仍然是O(1)：当散列表包含的元素增长太多的时候，散列表将被转换为正常的散列表（极限值可以在redis.conf进行配置）.

尽管从时间复杂度或常量时间的角度来看，采用这种encode理论上都不会有多大性能提升，但是，一个线性数组通常会被CPU的缓存更好的命中（线性数组有更好的局部性）,从而提升了访问的速度.

设置redis:

hash-max-ziplist-entries 512
hash-max-ziplist-value 1024

内存分配

maxmemory的值可以在配置文件中设置，或者在启动后通过 CONFIG SET 命令设置(see Using memory as an LRU cache for more info).

如果 maxmemory 没有设置，redis就会一直向OS申请内存，直到OS的所有内存都被使用完。所以通常建议设置上redis的内存限制，当redis的内存达到内存限制后，再向redis发送写指令，会返回一个内存耗尽的应用程序错误，但是不会导致整台机器宕掉.