Redis 对象共享池,性能优化小细节
如果你仔细研究过 Redis 中各种实现细节,你会发现为了性能,Redis 真的是不遗余力。
作为一种高性能的键值存储系统,Redis 广泛用于缓存、会话管理、消息队列等多种场景。
为了提高 Redis 在处理大量数据时的性能和效率,Redis 设计并实现了对象共享池(Shared Object Pool)这一内部机制。
那么接下来松哥就和大家详细说一说 Redis 中的对象共享池。
一 设计目的
Redis 的对象共享池主要用于复用一些常用的数据对象,以减少内存的开销。
在 Redis 中,一些常用的数据对象,主要是小整数(如 0 到 9999)等,是不会被改变的,因此可以安全地共享使用而无需重复创建。
例如你设置 set k1 99
和 set k2 99
,这时 k1 和 k2 其实指向的是同一个对象。
通过共享这些对象,Redis 能够显著降低内存的使用量,并减少对象的创建和销毁时间,从而提升整体性能。
二 工作原理
在 Redis 服务器启动时,会预先创建并存储一些常用的对象到一个全局的哈希表中,这个哈希表就是对象共享池。
当 Redis 需要处理一个键值对时,会首先检查这个键值对中的值是否已经在对象共享池中。如果已存在,Redis 将直接引用该对象,而不是创建一个新的对象。
三 支持的对象类型
目前主要是支持小整型,也就是 0~9999 之间的整数,浮点型数据不支持。
四 应用场景
对象共享池在多种场景下都能显著提升 Redis 的性能和效率,特别是在处理大量重复数据时。例如,在 Web 应用中,许多缓存的键值对可能包含相同的值,通过对象共享池,这些值可以被多个键值对共享,从而节省大量内存。
注意事项
只读性:对象共享池中的对象是只读的,不可修改。如果应用程序需要修改这些对象,Redis 会将其复制并创建一个新的对象进行操作。因此,在使用共享对象时,需要注意对象的可修改性。
内存策略:当 Redis 设置了最大内存值(maxmemory)并启用了 LRU(最近最少使用)等相关淘汰策略时,对象共享池可能会被禁用。这是因为在内存紧张的情况下,共享对象可能不再是最优选择。
五 实际案例
为了通过实际案例证明 Redis 中对象共享池的存在,我们可以结合 Redis 的内部机制和一些实际操作来进行分析。虽然 Redis 的官方文档没有直接提及“对象共享池”这一术语,但我们可以从 Redis 如何处理整数对象的共享中看到其背后的共享机制。
假设我们有一个 Redis 服务器,它用于存储和访问大量的键值对。在这些键值对中,有一部分键对应的值是常见的小整数。
我们来执行以下命令:
这里我要跟大家解释下。
OBJECT REFCOUNT 命令理论上可以查看某一个 key 对应的 value 被引用的次数。
所以我们期望第一次执行 OBJECT REFCOUNT k1
的时候返回 1,第二次执行 OBJECT REFCOUNT k1
的时候返回 2,但是实际上却并非如此,每次都是返回 2^31-1。
虽然这里并没有返回我们想要的值,但是大家可以看到,
OBJECT REFCOUNT k1
返回的值确实和 value 为字符串的 key 的返回值是不同的。
松哥来解释下原因。
通过分析 Redis 源码,松哥发现新版本的 redis 中 OBJ_SHARED_INTEGERS 变量定义了共享整数 10000,并且定义不被销毁的全局对象的引用数量 OBJ_SHARED_REFCOUNT 为 INT_MAX,INT_MAX = 2^31 - 1 =2147483647。
源码位置在:https://github.com/redis/redis/blob/unstable/src/server.h#L903。
并且从源码中可以看到当把一个对象设置为共享时候就会把 refcount 设置为 INT_MAX。
源码位置在:https://github.com/redis/redis/blob/unstable/src/object.c#L56。
从这里就能看出,如果某个对象的引用次数是 2^31-1,那么就说明这个对象是一个引用对象。
版权声明: 本文为 InfoQ 作者【江南一点雨】的原创文章。
原文链接:【http://xie.infoq.cn/article/dc050d657b558c46ed9584dac】。文章转载请联系作者。
评论