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

目录

空间和时间

HSET和HMSET

使用HSCAN

---

空间和时间

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

 

HSET和HMSET

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

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

 

执行完毕输出。

      数据写入完成后我们可以就用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的延迟：

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

 

使用HSCAN

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

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

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

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