揭秘Redis五大不常用数据类型

对于前一篇文章，已经详细讲解了redis中最关键的五个数据类型

streams数据类型

Redis 的 Streams 是一种专门为处理流式数据设计的高级数据类型，于 Redis 5.0 版本引入，提供了持久化、多消费者、消息确认等特性，非常适合构建消息队列、事件日志系统等场景。

核心特性

• 持久化：所有消息都被持久化到磁盘，重启后不丢失
• 有序性：消息按时间顺序存储，每个消息有唯一 ID
• 多消费者模式：支持多个消费者组同时消费，每个组独立维护消费进度
• 消息确认机制：确保消息被正确处理后才标记为已消费
• 灵活的读取方式：支持从开头、结尾、指定位置读取消息

基本概念

1. 消息（Message）：Streams 中的基本单位，包含唯一 ID 和键值对字段
2. 消费者组（Consumer Group）：一组消费者的集合，共同消费流中的消息
3. 消费者（Consumer）：消费者组中的具体成员，负责处理消息
4. 消息 ID：格式为 timestamp-sequence（如 1620000000000-0），确保唯一性和有序性

geospatial数据类型

Redis 的 Geospatial（地理空间）类型是一种专门用于存储和操作地理位置信息的数据结构，它允许你存储经纬度坐标，并提供了一系列用于地理位置计算的命令。

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

hyperloglog数据类型

Redis 的 HyperLogLog 是一种用于 cardinality（基数）统计的数据结构，它能够以极低的内存消耗（约 12KB）来估算一个集合中不重复元素的数量。

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

set，有一个应用场景，统计服务器的UV（用户访问的次数）

使用set当然可以统计UV，但是最大的问题在于，如果UV数据量非常大，set就会消耗很多的内存空间，假设set存储userid，每个userid按照8字节算，1亿UV==8亿字节==800mb

之所以要消耗这么大的空间，是因为set需要存储每个元素

而hyperloglog不存储元素的内容，但是能够记录”元素特征“，在新增元素的时候，能够知道当前元素是一个崭新的第一次出现的，还是一个已经存在的元素

只能用来计数，记录当前集合中有多少个不同的元素，但是不能告诉你这些元素都是啥

具体的操作需要分析源码---核心思路是”位操作“

这个是有一定的误差的

误差大概在百分之0.81，并且这个hyperloglog可以最多使用12kb空间就能够实现上述效果（每个 HyperLogLog 键仅占用约 12KB 内存，这个大小与其含有的数据量无关，无论是10还是100还是1个亿）

特别适合统计海量数据中的独立元素数量

适用场景：

• 网站独立访客（UV）统计
• 搜索引擎关键词去重计数
• 大型活动参与人数统计
• 任何需要统计不重复元素数量的场景（且可以接受一定误差）

局限性：

• 不存储实际元素，只记录基数估算值，无法获取具体元素
• 存在一定误差（约 0.81%），不适合需要精确计数的场景
• 无法删除已添加的元素

HyperLogLog 是空间与精度之间的一种平衡选择，当需要统计极大规模数据的基数且可以接受小误差时，它是非常理想的解决方案。

bitmaps数据类型

使用bit位来表示整数

0000 0000 0000 0000 0000 0000 0000 0000 0000

位图本质上，就还是一个集合，属于是set类型针对整数的特化版本

这个版本节省空间

bitfields数据类型

在c语言中我们学过位段，也叫做位域

struct Test{
int a:8;
int b:16;
int c:8;
}

这里的数据就是描述这几个成员实际占几个bit位的，位域本质上是让我们更精确进行位操作的一种方法

redis中的bitfields和c中的位域非常相似

bitfield可以理解成一串二进制序列（字节数组）

同时可以把这个字节数组中的某几个位，赋予特定的含义，并且可以进行读取/修改/算术运算相关操作

位域这个东西，相比于之前的string/hash来说，目的仍然是节省空间

BITFIELD 命令扩展了 Redis 字符串类型的位操作能力，使其能够更灵活地处理各种需要精细位控制的场景，特别适合需要高效利用内存存储大量小数值的情况。