通过前面的学习，我们已经学习了Redis最关键的五个数据结构：String、List、Hash、Set、ZSet。这五个数据结构应用广泛，频繁使用。

redis中包含的所有类型，下面将要介绍不常用的类型。

一、streams类型介绍

事件、epoll/IO多路复用，它就是一个事件驱动的方式。每次网卡/SOCKET上有可读可写的数据，都会通过这种事件机制来通知到自己的应用程序代码。所谓的事件：有些操作，我们也不知道它啥时候出现，只能这个事情出现了之后，再采取行动。官方文档的意思，就是streams类型就可以用来模拟实现这种事件传播的机制。

官方文档描述。

streams就是一个阻塞队列，redis作为一个消息队列的重要支撑。在工作用到这里的命令，我们可以查找官方文档就可以了。

二、geospatial类型介绍

英文翻译为地理空间。

这个类型的主要作用是存储坐标。

存储一些点之后，就可以让用户给定一个坐标，去从刚才存储的点里进行查找，（按照半径、矩形区域）。这个功能在地图应用中非常重要。

这是按照范围查找的应用。

三、hyperloglog类型介绍

应用场景只有一个，估算集合中的元素个数。

Set，有一个应用场景，统计服务器的UV（用户访问的次数），使用set当然可以统计UV，但是最大的问题在于，如果UV数据量非常大，Set就会消耗很多的内存空间。HyperLogLog最多可以使用12KB的空间实现上述效果。set之所以消耗这么大的空间Set需要存储每个元素，而HyperLogLog不存储元素的内容，但是能够记录元素的特征，从而在新增元素的时候，能够知道当前新增的元素是一个已经存在的元素，还是一个崭新的第一次出现的元素。用来计数，记录当前集合中有多少个不同的元素，但是不能告诉我们这些元素都是啥。但是这个类型会有一定的误差，官方文档为0.81%,这个类型不是Redis专有的。

四、bitmaps的介绍

这个类型为位图，使用bit位来表示整数。位图本质上，就还是一个集合，属于是Set类型针对整数的特化版本，为了节省空间来设计了这个类。计算机进行位运算，一般都是比较高效的。而hyperloglog既可以存储数字，也可以存储字符串，不存储元素内容，只是计数效果，而bitmap是存了元素的。hyperloglog存储元素的时候，提取特征的过程是不可逆的。猪肉做成火腿肠，火腿肠做不成猪肉。

五、bitfields类型

位域，c语言中，自定义数据类型 =》 结构体在内存中的布局 =》位段

位段也叫做位域。结构体成员后面加上冒号，后面加个数字

此处的数字，就描述这个成员实际占几个bit位！位于本质上是让我们精确进行位操作的一种方法。上述Redis中的bitfield和C中的位域，非常相似的！bitfield可以理解成一串二进制序列（字节数组），同时可以把这个字节数组中的某几个位，赋予特定的含义，并且进行读取/修改/算数运算相关操作。

位域这个东西，相比于之前的string还是要节省空间。

C语言和Redis中的bitfields的对比

六、渐进式遍历

keys一次性的把整个redis中所有的key都获取到，keys* 这个操作比较危险，可能会一下子得到太多的key，阻塞redis服务器。

通过渐进式遍历，就可以做到，既能够获取到所有的key，同时又不会卡死服务器。不是一个命令把所有的key都拿到，而是每次执行一次命令，只获取到其中的一小部分，这样的话保证当前这一次操作不会太卡。要想得到所有的key就需要多次遍历，多次执行渐进式遍历命令。化整为零。

渐进式遍历其实是一组命令，这一组命令的使用方法式一样的。主要是scan。

此处涉及到关键概念，光标。它就指向了当前遍历的位置。

光标设置为0了，以为着这次遍历是从头开始获取，返回值的前半部分是告诉你，下次继续遍历，光标要从哪里开始。

真正遍历到key的内容。

这里的cursor不能理解成下标，不是一个连续递增的整数！仅仅是一个字符串，光标这个概念程序员/客户端时不能认识的。redis服务器则知道这个光标对应的元素位置。

pattern和前面介绍过的keys命令是一样的。

COUNT 限制这一次遍历能够获取到多少个元素，默认是10。但是注意！此处的count和mysql的limit不一样。count只是给redis服务器一个提示或者建议。写入的count和实际返回的key的个数不一定是完全相同的，但是不会差很多。

TYPE：redis里的key都是string但是value的类型不一样。这次遍历就想要值为type类型的key。

scan命令返回的cursor回到0了，才说明遍历结束。scan是有可能返回空的集合的

整个的遍历过程

 时间复杂度为O(1)，count这里的数字，不是说每次遍历都得设置成一样。这里的渐进式遍历，在遍历过程中，不会在服务器这边存储任何的状态信息。此处的遍历时随时可以终止的，不会对服务器产生任何的副作用。

渐进式遍历scan虽然解决了阻塞的问题，但如果在遍历期间键有所变化（增加，修改，删除），可能导致遍历时键的重复遍历或者遗漏，这点务必在实际开发中考虑。这跟C++ STL遍历 + 修改/新增/删除 =》迭代器失效的问题相似。同理java中也是一样的。

虽然scan比keys要好点，但是使用的时候也还是有很多的注意事项，很多的出错是可能的。