最近⼯作中，系统压测遇到⼀个性能瓶颈问题，通过最终排查，发现应⽤接⼝中使⽤了⼤量的Hgetall命令从Redis中查询数据信息，导致Redis单实例OPS达到秒钟7W次，Redis服务器CPU使⽤率达到上限，遇到性能问题。 HGETALL key
起始版本：2.0.0
时间复杂度：O(N) where N is the size of the hash.
返回 key 指定的哈希集中所有的字段和值。返回值中，每个字段名的下⼀个是它的值，所以返回值的长度是哈希集⼤⼩的两倍
考考你的智商
返回值
：哈希集中字段和值的列表。当 key 指定的哈希集不存在时返回空列表。
例⼦
redis> HSET myhash field1 "Hello"
(integer) 1
redis> HSET myhash field2 "World"
渔趣网(integer) 1
redis> HGETALL myhash
1) "field1"
2) "Hello"苏轼的资料
3) "field2"
4) "World"
redis>
通过官⽅⽂档，可以了解到命令HgetAll的时间复杂度为O(n)。这意味着Hash的field越多，当使⽤HgetAll获取全量数
据时，性能越差，该命令的性能与field字段的数量成正⽐。
遇到问题后，上⽹查询资料，解决⽅案⼤致两种：
1) 借助MemCached
2) 新增⼀个field字段，将原Redis key对应的所有数据信息全部存储在该filed中，然后使⽤Hmget命令代替HgetAll
但是以上两种⽅案，均存在各种弊端，并没有从根本上解决问题。公司其他部门技术⼤拿交流，最终讨论出以下⽅案解决问题：
通过使⽤Redis dump命令获取到Redis序列化后的值，获取到的是字节数组。在应⽤中将该字节数组按照Redis协议⾃⾏解析成需要的HashMap数据。 ⽅案优点：
1) dump命令的时间复杂度为O(1)，性能优于HgetAll
瓶颈问题
2) 将字节数组的解析由Redis服务器转移到了应⽤服务器，减轻了Redis 服务器CPU的运算压⼒
3) 充分利⽤了应⽤服务器的CPU，并且应⽤服务器⽅便扩容。
DUMP key
起始版本：2.6.0
刚度矩阵时间复杂度：O(1) to access the key and additional O(N*M) to serialized it, where N is the number of Redis objects composing the value and M their average size. For small string values the time complexity is thus O(1)+O(1*M) where M is small, so simply O(1).
序列化给定 key ，并返回被序列化的值，使⽤ 命令可以将这个值反序列化为 Redis 键。
序列化⽣成的值有以下⼏个特点：
它带有 64 位的校验和，⽤于检测错误， 在进⾏反序列化之前会先检查校验和。
值的编码格式和 RDB ⽂件保持⼀致。
RDB 版本会被编码在序列化值当中，如果因为 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 会拒绝对这个值进⾏反序列化操作。
序列化的值不包括任何⽣存时间信息。
返回值
如果 key 不存在，那么返回 nil。</br> 否则，返回序列化之后的值。
例⼦
redis> SET mykey 10
颅内高压OK
redis> DUMP mykey
"\u0000\xC0\n\u0006\u0000\xF8r?\xC5\xFB\xFB_("
redis>
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议