Redis 新数据类型

Myth丶恋晨 2022-10-11 01:26 153阅读 0赞

# 1-Bitmaps #

## 1.1-Bitmaps 简介 ##

现代计算机用二进制（位）作为信息的基础单位，1 个字节等于 8 位，例如`abc`字符串是由 3 个字节组成，但实际在计算机存储时将其用二进制表示：`abc`分别对应的 ASCII 码分别是 97、98、99，对应的二进制分别是 01100001、01100010、01100011，如下图：  
![在这里插入图片描述][20210629221435692.png]  
合理的使用操作位能够有效地提高内存使用率和开发效率。

Redis 提供了 Bitmaps 数据类型可以实现对位的操作：

*  Bitmaps 本身不是一种数据类型，实际上它就是字符串（key-value），但是它可以对字符串的位进行操作。
 *  Bitmaps 单独提供了一套命令，所以在 Redis 中使用 Bitmaps 和使用字符串的方法不太相同。可以把 Bitmaps 想象成一个以位为单位的数组，数组的每个单元只能存储 0 和 1，数组的下标在 Bitmaps 中叫做偏移量。  
    ![在这里插入图片描述][20210629221443510.png]

## 1.2-常用命令 ##

### 1.2.1-SETBIT ###

**命令：**

SETBIT key offset value

**说明：**

*  对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。
 *  位的设置或清除取决于 **value 参数，可以是 0 也可以是 1**。
 *  当 key 不存在时，自动生成一个新的字符串值。
 *  字符串会进行伸展(grown)以确保它可以将 value 保存在指定的偏移量上。当字符串值进行伸展时，空白位置以 0 填充。
 *  offset 参数必须**大于或等于 0**，小于 2^32 (bit 映射被限制在 512 MB 之内)。
 *  对使用大的 offset 的 SETBIT 操作来说，内存分配可能造成 Redis 服务器被阻塞。具体参考 SETRANGE 命令，warning（警告）部分。

**返回值：**

*  指定偏移量原来储存的位。

**实例：**

每个独立用户是否访问过网站存放在 Bitmaps 中，将访问的用户记做 1，没有访问的用户记做 0，用偏移量作为用户的 ID。  
设置键的第 offset 个位的值（从 0 算起），假设现在有 20 个用户，`UserId = 1, 6, 11, 15, 19`的用户对网站进行了访问，那么当前 Bitmaps 初始化结果如图：  
![在这里插入图片描述][20210629221458797.png]  
`unique:users:20201106`代表`2020-11-06`这天的独立访问用户的 Bitmaps  
![在这里插入图片描述][2021062922150927.png]  
**注**：

*  很多应用的用户ID以一个指定数字（例如 10000）开头，直接将用户 ID 和 Bitmaps 的偏移量对应势必会造成一定的浪费，通常的做法是每次做 SETBIT 操作时将用户 ID 减去这个指定数字。
 *  在第一次初始化 Bitmaps 时，假如偏移量非常大，那么整个初始化过程执行会比较慢，可能会造成 Redis 的阻塞。

### 1.2.2-GETBIT ###

**命令：**

GETBIT key offset

**说明：**

*  对 key 所储存的字符串值，获取指定偏移量上的位(bit)。
 *  当 offset 比字符串值的长度大，或者 key 不存在时，返回 0。

**返回值：**

*  字符串值指定偏移量上的位(bit)。

**实例：**

获取`用户 ID = 8`的用户是否在`2020-11-06`这天访问过，返回 0 说明没有访问过：  
![在这里插入图片描述][20210629221526243.png]  
注：因为 100 根本不存在，所以也是返回 0。

### 1.2.3-BITCOUNT ###

**命令：**

BITCOUNT key [start] [end]

**说明：**

*  计算给定字符串中，被设置为 1 的比特位的数量。
 *  一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。
 *  start 和 end 参数的设置和 GETRANGE 命令类似，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，以此类推。
 *  不存在的 key 被当成是空字符串来处理，因此对一个不存在的 key 进行 BITCOUNT 操作，结果为 0。

**返回值：**

*  被设置为 1 的位的数量。

**实例：**

*  计算`2020-11-06`这天的独立访问用户数量：  
    ![在这里插入图片描述][2021062922153945.png]  
    start 和 end 代表起始和结束字节数，下面操作计算用户 ID 在第 1 个字节到第 3 个字节之间的独立访问用户数，对应的用户 ID 是**11, 15, 19**。  
    ![在这里插入图片描述][20210629221543847.png]
 *  K1 \[01000001 01000000 00000000 00100001\]，对应 \[0, 1, 2, 3\]：
    
     *  `bitcount K1 1 2`：统计下标 1、2 字节组中`bit = 1`的个数，即 \[01000000 00000000\]，`bitcount K1 1 2 --> 1`。
     *  `bitcount K1 1 3`：统计下标 1、2 字节组中`bit = 1`的个数，即 \[01000000 00000000 00100001\]，`bitcount K1 1 3 --> 3`。
     *  `bitcount K1 0 -2`：统计下标 0 到下标倒数第 2，字节组中`bit = 1`的个数，即 \[01000001 01000000 00000000\]，`bitcount K1 0 -2 --> 3`。

**注意**：Redis 的 SETBIT 设置或清除的是 bit 位置，而 BITCOUNT 计算的是 byte 位置。

### 1.2.4-BITOP ###

**命令：**

BITOP operation destkey key [key ...]

**说明：**

*  对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
 *  operation 可以是 AND（交集）、OR（并集）、NOT（非）、XOR（异或） 这四种操作中的任意一种：
    
     *  BITOP AND destkey key \[key …\]：对一个或多个 key 求逻辑并，并将结果保存到 destkey。
     *  BITOP OR destkey key \[key …\]：对一个或多个 key 求逻辑或，并将结果保存到 destkey。
     *  BITOP XOR destkey key \[key …\]：对一个或多个 key 求逻辑异或，并将结果保存到 destkey。
     *  BITOP NOT destkey key：对给定 key 求逻辑非，并将结果保存到 destkey。
 *  除了 NOT 操作之外，其他操作都可以接受一个或多个 key 作为输入。
 *  处理不同长度的字符串：
    
     *  当 BITOP 处理不同长度的字符串时，较短的那个字符串所缺少的部分会被看作 0。
     *  空的 key 也被看作是包含 0 的字符串序列。

**返回值：**

*  保存到 destkey 的字符串的长度，和输入 key 中最长的字符串长度相等。

**实例：**

*  `2020-11-04`日访问网站的`UserId = 1, 2, 5, 9`：
    
        setbit unique:users:20201104 1 1
        setbit unique:users:20201104 2 1
        setbit unique:users:20201104 5 1
        setbit unique:users:20201104 9 1
 *  `2020-11-03`日访问网站的`UserId = 0, 1, 4, 9`：
    
        setbit unique:users:20201103 0 1
        setbit unique:users:20201103 1 1
        setbit unique:users:20201103 4 1
        setbit unique:users:20201103 9 1

计算出两天都访问过网站的用户数量：

bitop and unique:users:and:20201104_03
    unique:users:20201103unique:users:20201104

![在这里插入图片描述][20210629221601853.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3loajE5OTIwNDE3_size_16_color_FFFFFF_t_70]  
计算出任意一天都访问过网站的用户数量（例如月活跃就是类似这种），可以使用 OR 求并集：  
![在这里插入图片描述][20210629221612327.png]

## 1.3-与 Set 比较 ##

假设网站有 1亿用户，每天独立访问的用户有 5 千万，若每天用集合类型和 Bitmaps 分别存储活跃用户可以得到表：  
![在这里插入图片描述][20210705222801444.png]  
很明显，这种情况下使用 Bitmaps 能节省很多的内存空间，尤其是随着时间推移节省的内存还是非常可观的：  
![在这里插入图片描述][20210705223044796.png]  
但 Bitmaps 并不是万金油，假如该网站每天的独立访问用户很少，例如只有 10 万（大量的僵尸用户），那么两者的对比如下表所示：  
![在这里插入图片描述][20210705223334565.png]  
很显然，这时候使用 Bitmaps 就不太合适了，因为基本上大部分位都是 0。

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

# 2-HyperLogLog #

## 2.1-HyperLogLog 简介 ##

在工作中经常会遇到与统计相关的功能需求，比如统计网站 PV（Page View 页面访问量），可以使用 Redis 的 INCR、INCRBY 轻松实现。

但像 UV（Unique Visitor 独立访客）、独立 IP 数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为**基数问题**。

**解决基数问题有很多种方案**：

*  数据存储在 MySQL 表中，使用`distinct count`计算不重复个数。
 *  使用 Redis 提供的 Hash、Set、Bitmaps 等数据结构来处理。

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。

能否能够降低一定的精度来平衡存储空间？Redis 推出了 HyperLogLog：

*  Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
 *  在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
 *  但是因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数？

比如数据集`{1, 3, 5, 7, 5, 7, 8}`，那么这个数据集的基数集为`{1, 3, 5 ,7, 8}`，基数（不重复元素）为 5。 基数估计就是在误差可接受的范围内，快速计算基数。

## 2.2-常用命令 ##

### 2.2.1-PFADD ###

**命令：**

PFADD key element [element ...]

**说明：**

*  将所有元素参数添加到 HyperLogLog 数据结构中。

**返回值：**

*  若至少有个元素被添加返回 1， 否则返回 0。

**实例：**  
![在这里插入图片描述][2021062922175931.png]

### 2.2.2-PFCOUNT ###

**命令：**

PFCOUNT key [key ...]

**说明：**

*  返回给定 HyperLogLog 的基数估算值。

**返回值：**

*  返回给定 HyperLogLog 的基数值，如果多个 HyperLogLog 则返回基数估值之和。

**实例：**  
![在这里插入图片描述][2021062922180861.png]

### 2.2.3-PFMERGE ###

**命令：**

PFMERGE destkey sourcekey [sourcekey ...]

**说明：**

*  将多个 HyperLogLog 合并为一个 HyperLogLog，合并后的 HyperLogLog 的基数估算值是通过对所有给定 HyperLogLog 进行并集计算得出的。比如每月活跃用户可以使用每天的活跃用户来合并计算可得。

**返回值：**

*  返回 OK。

**实例：**  
![在这里插入图片描述][20210629221819665.png]

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

# 3-Geospatial #

## 3.1-Geospatial 简介 ##

Redis 3.2 中增加了对 GEO 类型的支持。GEO(Geographic)地理信息的缩写。该类型就是空间元素的二维坐标，在地图上就是经纬度。Redis 基于该类型，提供了经纬度设置、查询、范围查询、距离查询、经纬度 Hash 等常见操作。

## 3.2-常用命令 ##

### 3.2.1-GEOADD ###

**命令：**

GEOADD key longitude latitude member [longitude latitude member ...]

**说明：**

*  存储指定的地理空间位置，可以将一个或多个经度(longitude)、纬度(latitude)、位置名称(member)添加到指定的 key 中。

**返回值：**

*  新添加到 key 里面的空间元素数量，不包括那些已经存在但是被更新的元素。

**实例：**

geoadd china:city 121.47 31.23 shanghai
    geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shenzhen 116.38 39.90 beijing

![在这里插入图片描述][20210629221830749.png]  
**注**：

*  两极数据无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。
 *  有效的经度从 -180 度到 180 度，有效的纬度从 -85.05112878 度到 85.05112878 度。
 *  当坐标位置超出指定范围时，该命令将会返回一个错误。
 *  已经添加的数据，是无法再次往里面添加的。

### 3.2.2-GEOPOS ###

**命令：**

GEOPOS key member [member ...]

**说明：**

*  从 key 里面返回所有给定位置元素的位置（经度和纬度）。
 *  GEOPOS 命令接受可变数量的位置元素作为输入，即使用户只给定了一个位置元素，命令也会返回数组回复。

**返回值：**

*  GEOPOS 命令返回一个数组，数组中的每个项都由两个元素组成：第一个元素为给定位置元素的经度，而第二个元素则为给定位置元素的纬度。当给定的位置元素不存在时，对应的数组项为空值。

**实例：**  
![在这里插入图片描述][20210629221840299.png]

### 3.2.3-GEODIST ###

**命令：**

GEODIST key member1 member2 [m|km|ft|mi]

**说明：**

*  返回两个给定位置之间的距离。
 *  若两个位置之间的其中一个不存在， 那么命令返回空值。
 *  指定单位的参数 unit 必须是以下单位的其中一个：
    
     *  m：表示单位为米。
     *  km：表示单位为千米。
     *  mi：表示单位为英里。
     *  ft：表示单位为英尺。
 *  若用户没有显式地指定单位参数，那么 GEODIST 默认使用米作为单位。
 *  GEODIST 命令在计算距离时会假设地球为完美的球形，在极限情况下，这一假设最大会造成 0.5% 的误差。

**返回值：**

*  计算出的距离会以双精度浮点数的形式被返回。
 *  若给定的位置元素不存在，那么命令返回空值。

**实例：**

获取两个位置之间的直线距离  
![在这里插入图片描述][20210705231037707.png]

### 3.2.4-GEORADIUS ###

**命令：**

GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [ASC|DESC] [COUNT count]

**说明：**

*  以给定的经纬度为中心，返回键包含的位置元素当中，与中心的距离不超过给定最大距离的所有位置元素。
 *  范围可以使用以下其中一个单位：
    
     *  m：表示单位为米。
     *  km：表示单位为千米。
     *  mi：表示单位为英里。
     *  ft：表示单位为英尺。
 *  在给定以下可选项时，命令会返回额外的信息：
    
     *  WITHDIST：在返回位置元素的同时，将位置元素与中心之间的距离也一并返回。距离的单位和用户给定的范围单位保持一致。
     *  WITHCOORD：将位置元素的经度和维度也一并返回。
     *  WITHHASH：以 52 位有符号整数的形式，返回位置元素经过原始 geohash 编码的有序集合分值。这个选项主要用于底层应用或者调试，实际中的作用并不大。
 *  命令默认返回未排序的位置元素，通过以下两个参数，用户可以指定被返回位置元素的排序方式：
    
     *  ASC：根据中心的位置，按照从近到远的方式返回位置元素。
     *  DESC：根据中心的位置，按照从远到近的方式返回位置元素。
 *  在默认情况下，GEORADIUS 命令会返回所有匹配的位置元素。虽然用户可以使用`COUNT <count>`选项去获取前 N 个匹配元素，但是因为命令在内部可能会需要对所有被匹配的元素进行处理，所以在对一个非常大的区域进行搜索时，即使只使用 COUNT 选项去获取少量元素，命令的执行速度也可能会非常慢。但是从另一方面来说，使用 COUNT 选项去减少需要返回的元素数量，对于减少带宽来说仍然是非常有用的。

**返回值：**

*  GEORADIUS 命令返回一个数组，具体来说：
    
     *  在没有给定任何 WITH 选项的情况下，命令只会返回一个像`["New York","Milan","Paris"]`这样的线性(linear)列表。
     *  在指定了 WITHCOORD、WITHDIST、WITHHASH 等选项的情况下，命令返回一个二层嵌套数组，内层的每个子数组就表示一个元素。
 *  在返回嵌套数组时，子数组的第一个元素总是位置元素的名字。至于额外的信息，则会作为子数组的后续元素，按照以下顺序被返回：
    
     *  以浮点数格式返回的中心与位置元素之间的距离，单位与用户指定范围时的单位一致。
     *  geohash 整数。
     *  由两个元素组成的坐标，分别为经度和纬度。
 *  示例：`GEORADIUS Sicily 15 37 200 km withcoord withdist`这样的命令返回的每个子数组都是类似以下格式的：`["Palermo","190.4424",["13.361389338970184","38.115556395496299"]]`

**实例：**  
![在这里插入图片描述][20210705231200841.png]

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

[20210629221435692.png]: /images/20221005/52df1a986eea424f9202eae10b9adb33.png
[20210629221443510.png]: /images/20221005/de1416a1eb4a450bb97a894eec0d21f7.png
[20210629221458797.png]: /images/20221005/9d9affeba7214c478bd910b9cf9e8c06.png
[2021062922150927.png]: /images/20221005/d522cb0b026348279aa19f98d00aa344.png
[20210629221526243.png]: /images/20221005/3128d72637574a92bf9d025f265e0db6.png
[2021062922153945.png]: /images/20221005/0aeea919e8e8440eb4bff2bda9bf8ab2.png
[20210629221543847.png]: /images/20221005/12e91cb017c447a89200016ecfbdfe14.png
[20210629221601853.png]: /images/20221005/8142ba5197ef4d218f9c3167b66b6a61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3loajE5OTIwNDE3_size_16_color_FFFFFF_t_70]: /images/20221005/7bb9f0803d2d4e12a36b22907c3b04be.png
[20210629221612327.png]: /images/20221005/bba6f3ab0b3c4abbae6840d932513c85.png
[20210705222801444.png]: /images/20221005/f9ccb09238b440d49d1be7207e2c8c2d.png
[20210705223044796.png]: /images/20221005/6b7a3700c79c417084288bf953d899ce.png
[20210705223334565.png]: /images/20221005/de55abafef734f4dae6929789929bb3f.png
[2021062922175931.png]: /images/20221005/ceffc9ebe191432dab25bf4ba0950c4e.png
[2021062922180861.png]: /images/20221005/2d82a9d620b542558e52e36a2a78786b.png
[20210629221819665.png]: /images/20221005/0ff698fc65234fdba56e5b0fc23db09c.png
[20210629221830749.png]: /images/20221005/8ae6490df9ec446fb483508135bd447e.png
[20210629221840299.png]: /images/20221005/2d10429ab89a441bb6251278d3c265d5.png
[20210705231037707.png]: /images/20221005/57093e12fb1f4fd79f209fb026660c83.png
[20210705231200841.png]: /images/20221005/844c53968413436cb07b974f98e8e4a4.png