首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

记Redis那坑人的HGETALL

早就听人说过Redis的HGETALL是个坑,可我偏偏不信邪:不管什么坑,一定要自己踩上去跺两脚才肯罢休。说好听点这是不到黄河心不死,说难听点就是不见棺材不落泪。...开始程序运行的非常稳定,稳定到我想送所有说HGETALL是个坑的人一个字:呸!...此时的我就像温水里的青蛙一样忘记了危险的存在,时间就这样一天一天的过去,突然有一天需求变了,我不得不把HASH数据的内容从十几个字段扩展到一百多个字段,同时使用了Pipelining一次性获取上百个HGETALL...通常请求都会很快处理完,但是当我们使用HGETALL的时候,必须遍历每个字段来获取数据,这期间消耗的CPU资源和字段数成正比,如果还用了PIPELINING,无疑更是雪上加霜。 如何解决这个问题?...具体来说,我大致想到了以下几种方法: 借助Memcached Redis存储方式不做任何改变,额外的,我们借助Memcached实现一套缓存,里面存储原本需要在Redis里HGETALL的HASH,当然

49430
您找到你想要的搜索结果了吗?
是的
没有找到

redis源码之hash结构的实现

hash结构中,存在这样一种现象 127.0.0.1:6379> hset user:001 name john age 25 sex man (integer) 3 127.0.0.1:6379> hgetall...user:001 1) "name" 2) "john" 3) "age" 4) "25" 5) "sex" 6) "man" 我们先给user:001分别设置了name,age,sex属性,然后通过hgetall...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (integer) 4 127.0.0.1:6379> hgetall...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 5) "sex" 6) "man" 7) "age" 8) "25" 我们给user:002多设置了一个extra属性,并且设置的值比较大,然后用hgetall...hash-max-ziplist-value 64 //单个元素大小超过64byte时,将改为hashtable编码 对于上面的例子,主要是因为单个元素大小超过了64byte,所以改为了hashtable编码,导致了hgetall

50250
领券