Redis内存优化：使用不同的接口操作数据

喜欢ヅ旅行 2023-01-16 15:23 120阅读 0赞

**目录**

空间和时间

HSET和HMSET

使用HSCAN

--------------------

## 空间和时间 ##

接着看关于Redis内存使用的一些优化方式，上一篇日志讲到用不同的数据类型，JSON字符串和Hash存储都比String类型存储有很大的内存节省。总的来说，在不同场景中使用不同的存储方式达到内存消耗尽可能小，来提升查询的性能，例如举个例子，在计算一个博客里面的访客数时，最快想到的可能是使用集合存储，或者使用HyperLogLog数据类型也可以，因为每一个用户都是唯一的，基数统计可以很方便做到统计基数任务。还可以用位图，还记得吧，bitmap的优点是很节省空间，存储布尔信息，用一个位来表示数据是否被访问过。以上是从内存消耗方面来考虑，也就是空间方面，除此之外，还可以从另外的角度，时间方面来考虑对Redis的优化。Redis对比起关系型数据库的优势是查询延迟低，效率高，因为Redis实现并提供了很多数据结构和高效使用它们的接口，所以在程序开发中可以根据场景使用不同的API来达到效率优化的目的。

## HSET和HMSET ##

HSET命令往哈希表里添加、修改数据，如果想一次性设置多个键的值，可以用HMSET，在一次客户端和服务器通信之间完成多条数据操作来减少网络开销，首先我们写个脚本，使用这两个API来写入大量数据：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70][]

数据写入完成后，用redis-cli FLUSHALL命令先把整个 Redis 服务器的数据清空也就是删除数据库的所有key。成功清除会输出“OK”接着我们用命令bash hset\_hmset.sh来执行这个脚本：

![20210426123937165.PNG][]

![20210426123946379.PNG][]

执行完毕输出。

数据写入完成后我们可以就用redis-cli HGETALL命令获取我们刚刚写入的所有数据，在运行这条指令前，我们先另外打开一个控制台，执行redis-cli –latency命令，改命令可以检测Redis的延迟，它的输出有4个指标，min、max、avg和sample。min最小值表示的是命令发出PING的数间和收到回复的时间间隔最小延迟，max自然就是指的最大延迟，avg指的是平均响应时间，sample样本指的是redis-cli发出的PING命令和接受响应的次数，及请求和响应的次数。

我们用一个控制台执行redis-cli HGETALL命令获取数据，一个控制台执行redis-cli –latency命令查看获取过程中Redis的延迟：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 1][]

![20210426124029256.PNG][]

可以看到此时的延迟还是较大的。之前我们在哈希数据类型的日志里总结过，如果一个哈希字段非常多，使用HGETALL命令很可能引起服务器阻塞，因为Redis是单线程的，单线程数据存储服务，当其正在处理一个请求时，其他的请求便只能等待，HGETALL命令需要遍历每一个字段来获取数据，当数据量很大时，消耗的CPU资源也会变大。那怎么办？

## 使用HSCAN ##

解决方式是使用其他API来获取Redis中的数据，如HSCAN，该命令以迭代式，增量地遍历哈希键中的键值对，每次只会返回少量的查询结果。来看一个例子，我们写个脚本使用HSCAN命令来遍历所有的用户数据：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 2][]

这个时候我们再执行这个脚本，并在另一个控制台中重新使用redis-cli –latency命令查看延迟：

![20210426124048676.PNG][]

可以看到，延迟比起使用HGETALL命令，有了很大的改善。造成HGETALL命令延迟这么高，耗时的原因上面有简单提到，就是Redis是单线程数据存储服务，在处理一个请求时，其他的请求便只能等待。翻看Redis文档，可以看到HGETALL命令的时间复杂度为N：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 3][]

其中N is the size of the hash，即哈希的大小，在我们上面的测试用例中，N的大小是100000，长时间的数据获取使得Redis在此期间无法响应任何其他的请求，改为HSCAN后，该命令会逐渐遍历每一个键，增量式，多次返回查询结构，来降低一次Redis操作的往返时延，即从客户但向服务器发送命令开始，经过服务器接受命令，放置到执行队列中，到命令被执行，执行结果返回给客户端的过程，倘若使用HGETALL命令，该命令被从Redis执行队列中拿出来执行后，会一直占据服务器，甚至阻塞。通过使用HGETALL和HSCAN的对比，体现出Redis的优化不仅可以从存储的数据类型方面，还可以通过使用不同的API操作数据，达到优化的目的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70]: /images/20221022/5a7bf90920ff4b579ab0fa706f97ffec.png
[20210426123937165.PNG]: /images/20221022/dfb005ed2e2147598d94a903228e8991.png
[20210426123946379.PNG]: /images/20221022/1e6d54cb1bfa411e8c06e36a8747df7c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 1]: /images/20221022/ac094d375dad4669b65ad76998f95156.png
[20210426124029256.PNG]: /images/20221022/13ad16f6d83f44e8bd7eccbe953a54f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 2]: /images/20221022/657b23858dd54321821d10d92bd378d0.png
[20210426124048676.PNG]: /images/20221022/6216953e916d499cbf86485404863096.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 3]: /images/20221022/48e7252b434e4f37b913d6c897d478e2.png