c# redis hashid如何设置过期时间_Redis内存管理：配置与版本事项

这一节我们先简单聊一下redis配置与版本注意事项，涉及到配置，键的过期、32位redis和64位的区别，后续我们再来了解Redis LRU键的驱逐策略以及具体的优化策略。

1、配置redis

如果要运行一个高效的redis，我们必须要理解redis.conf文件中所有的内存相关指令，当然redis.conf文件提供了丰富内联文档使我们可以更好的理解、更改和测试相关配置项，本节我们先简单回顾用来配置redis的内存相关的指令，这些都可以在redis.conf文件中进行设置，在运行时我们可以通过CONFIG SET指令来设置。

• rdbchecksum：默认值为Yes，将一个65位的冗余检验码(CRC64)放在RDB快照文件的尾末(RDB是redis持久化文件的一种,请参考面试官问：Redis数据丢失咋办？如何持久化它？)，以此来发防止文件损坏，当redis开启子进程将数据持久化到RDB快照文件时，而我们需要注意的是对快照文件进行CRC64校验会增加10%的内存使用。
• activerehashing：如果设置为yes，那么redis会在每隔100毫秒会重新哈希，重新哈希会是释放已经删除的键所占用的内存空间，如果对redis服务器没有指定硬性响应时间，建议设置为no，从而及时释放内存，说白设置为no可以提高响应速率，但内存占用较大，设置为yes后及时释放了内存空间，但遇到高并发量的客户端时可能降低了响应时间。
• slave-of：主从复制可以提高可伸缩性，如果你的redis运行在集群环境中我们可以通过slave-of指令将redis切换到从模式，这是该从实例可以从另一个被指定为主实例的redis中复制数据，主从模式下提升redis的冗余度是在内存、硬件和网络IO之间做出的权衡。

2、键过期

保证redis数据库不会内存溢出简单有可靠的方法是为键设置过期时间，有了过期时间键会自动被驱逐，为你应用程序设计一套高效的过期策略可以使你的内存需求更高效可控，我们需要注意的是一旦在键上调用EXPIRE命令来设置过期时间，该超时只能通过删除或替换键的方式清除，任何改变值的操作都不能清除该设置的超时：

redis>SET  myname  aa #设置一个key为myname的键okredis>EXPIRE  myname 300 #过期时间设为300秒(integer) 1redis>TTL myname #检测一下过期时间(integer) 287redis>APPEND myname pp #使用append命令追加值(integer) 4redis>GET myname #查看新值"aapp"redis>TTL myname  #再次检测一下过期时间"259"

可以看到值被修改后超时依然存在，如果需要清除这个超时设置可以在这个键上调用set或getset命令，ttl返回-1表示没有设置超时时间的默认值：

redis> TTL myname #检测过期时间(integer) 200redis> SET myname cc #set命令okredis> TTL myname  #再次检测过期时间 值为-1(integer) -1redis>persist myname  #也可以使用persist命令来清除键的过期时间：(integer)  1redis>persist myname  #也可以使用persist命令来清除键的过期时间：(integer)  1

需要注意的是如果对一个键设了过期时间，但此时数据库进程被关闭了，在redis重启之后会自动驱逐该键值。

3、32位的redis

对于小于3GB数据集情况下，在32位redis实例中要比64为版本小、这里我们来看两个redis实例：redisIns32，redisIns64，然后在python命令行创建测试函数,分别对每个实例设置10000个键值对：

>>> def myrRedisTest()：  for i  in range(10000):    key = "uuid:{}".format(i)    value=uuid.uuid4()    redisIns32.set(key,value)    redisIns64.set(key,value)>>>def myrRedisTest()

再来看下redis中使用INFO memory查看内存使用情况：

#32位redis实例输出redis>INFO memory ...used_memory_human:11.87M #redis分配的内存大小used_peak_human:11.87M #redis使用峰值内存...#64位redis实例输出redis>INFO memory ...used_memory_human:14.18M #redis分配的内存大小used_peak_human:14.18M #redis使用峰值内存...

我们看到了相同的数据32位实例和64位实例的内部占用差异，下面我们列举一百万个整数、浮点数、字符串、哈希结构以及列表使用的内存对比。

整数、浮点数、字符串的测试对比：

一百万个整数、浮点数、字符串redis使用版本比较

• 图中显示如果使用整数，64位redis多使用了36%的内存，只要redis总使用内存不超过4GB，那32位版本的redis节省的内存也是很可观了。
• 对于大量使用集合字符串的应用来说，显然64位版本的redis多出的内存不太明显，仅仅多了22%，并且64位版本的redis对字符串有大量的额外空间和编码优化，所以推荐使用64位版本。

哈希结构对比：

哈希数据结构内存使用对比

对于哈希结构来说，无论存储什么类型，32位和64位之间差异都是基本定在了19-19.56之间。

列表结构对比

列表数据结构的内存使用对比

可以看到在32位限制之下，列表非常适合存储整数和浮点数，字符串在32位和64位之间的内存使用率差异最小。

32位版本redis的注意事项

• 由于32位版本的redis并未在用户群中广发部署和测试，较于64位版本来说可能有未发现的bug。
• 诸如BITOP和BITCOUNT的位操作、字符串都在64位版本上做了优化。
• 如果redis配置中参数maxmemory值设置的过于接近4GB，那么redis在通信、复制、IO缓存都有可能阻塞甚至崩溃。

个人理解有所纰漏，还请老铁们多多指教，下一节我们来讲解【Redis LRU键的驱逐策略】后续持续更新！