Redis存储⑦其它数据类型+渐进式遍历+数据库管理-优快云博客

1. 其它数据类型

在 Redis 中不仅只包含前面说的五种基本数据类型：String、List、Hash、Set、Zset，Redis 还提供了其他的数据类型来使得 Redis 适合在一些特殊的使用场景下使用。（其它数据类型很少用到，这里只做简单介绍，需要用到时可以查阅官方文档。）

1.1 Stream

Redis Stream 是 Redis 5.0 中引入的一种数据类型，它提供了一种处理 Redis 数据库中数据流的方法。它主要设计用于消息传递和事件源应用程序，为存储和处理消息或事件序列提供强大且可扩展的解决方案。

Redis Stream 类型具有以下主要功能：

附加消息：与日志结构类似，我们可以在流的末尾附加新消息或事件。流中的每个条目都分配有一个唯一的 ID，该 ID 通常是确保顺序的基于时间戳的标识符。
持久存储：添加到流中的消息会被持久存储，这使得 Redis Streams 适合需要可靠消息存储的应用程序，例如消息队列或日志系统。
消费者和消费者组：Redis Streams支持多个消费者和消费者组，允许不同的消费者处理消息。该模型支持复杂的分布式应用程序，其中处理可能需要在多个节点之间划分。
阻塞读取：消费者可以以阻塞方式从流中读取数据，如果已经处理完所有可用消息，则等待新消息。此功能对于实时消息处理非常有用。
复杂操作支持：Redis 提供了一系列与流交互的命令，例如XADD添加消息、XRANGE检索XREVRANGE一系列消息、XREAD从一个或多个流读取以及XGROUP管理消费者组。
可扩展性和效率：Redis Streams 旨在高效处理大量消息，无论是在内存使用还是性能方面。

Redis Streams 在涉及实时数据馈送、日志聚合、微服务架构中的事件源以及构建消息队列的场景中特别有用。它们为管理数据流提供了高性能、耐用且易于使用的解决方案。

对于 Stream 类型，主要有四种命令：XADD、XREAD、XRANGE和XLEN。

XADD：向流中添加新的条目
XREAD：读取一个或多个条目，从给定位置开始，并在时间上向前移动。
XRANGE：返回两个提供的条目id范围之间的条目
XLEN：返回流的长度

1.2 Geospatial

Geospatial 允许基于经度和纬度坐标存储、检索和查询地理空间数据。此功能构建在 Redis 的排序集之上，提供高效的地理空间数据索引和查询。这些命令还可以提供附加信息，例如返回的项目距搜索半径中心的距离，并且可以返回按距离排序的结果。

地理空间数据存储：Redis使用GEOADD命令来存储地理空间数据。此命令将一个或多个元素添加到 Redis 排序集中，每个元素由经度和纬度坐标以及位置名称组成。
半径查询：GEORADIUS和GEORADIUSBYMEMBER命令允许查询一定半径内的地理空间数据。GEORADIUS根据项目与给定坐标集的距离返回项目，而GEORADIUSBYMEMBER根据项目与已存储在地理空间索引中的位置的距离返回项目。
距离计算：该GEODIST命令计算数据集中两个地理空间项目之间的距离。它可以以各种单位（米、公里、英里或英尺）返回距离，从而根据应用要求提供灵活性。
位置检索：使用该GEOPOS命令，您可以检索地理空间索引中一项或多项的经度和纬度坐标。
哈希表示：该GEOHASH命令返回一个或多个元素位置的 Geohash 字符串表示。 Geohash 是一种将地理位置编码为短字母和数字字符串的系统，这对于利用此类表示的应用程序非常有用。

1.3 HyperLogLog

Redis HyperLogLog 是一种概率数据结构，提供了一种有效的方法来估计数据集的基数，即数据集中唯一元素的数量。 HyperLogLog 对于不需要精确计数但近似值就足够的大型数据集和应用程序特别有用，尤其是在节省内存至关重要时。HyperLogLog 不存储元素具体的值，而是存储元素的特征，这也正是 HyperLogLog 节省内存的关键。

HyperLogLog 类型具有下面特点：

空间效率：HyperLogLog 可以仅使用大约 12 KB 的内存来估计超过 10 亿个唯一项目的基数，标准误差为 0.81%。与需要更多内存来存储所有独特元素的传统方法相比，这使得它具有高度的空间效率。
易于使用：Redis 提供了一组简单的命令来操作 HyperLogLog 数据类型，从而可以轻松集成到应用程序中。
合并功能：可以将多个 HyperLogLog 合并在一起，以创建一个结合其数据集的单个 HyperLogLog。此功能在数据在不同位置或不同时间收集的分布式系统中特别有用。

1.4 Bitmap

Redis bitmap 不是一种独特的数据类型，而是一组应用于 Redis 字符串的位级操作。这些字符串本质上是一个位数组，并且它们非常节省空间。位图对于涉及计算唯一用户、功能切换的场景或需要在数据集中的任意位置操作和测试位的任何其他场景非常有用。

bitmap 的主要特点：

空间效率：位图使用很少的内存，这使得它们非常适合表示具有高基数的数据，例如数百万用户或对象，特别是当您跟踪简单的二进制状态（例如，活动/非活动、已访问/未访问）时。
位级操作：Redis 提供命令来设置、清除和测试字符串中特定位置的位、计算设置位、查找设置或未设置位等。
原子位操作：设置位或测试位等操作是原子的，使得 Redis 位图适合并发用例。

1.5 Bitfield

RedisBITFIELD是 Redis 3.2 中引入的命令，与标准位图操作相比，它允许用户以更精细的方式对字符串（Redis 表示为位数组）执行复杂的操作。它扩展了 Redis 的能力，以处理较大字符串（或位图）中的不同位宽度和任意非字节对齐字段。此功能提供了对如何在大型位数组中存储和操作整数的更高程度的控制，从而针对特定用例优化了空间和性能。

BITFIELD 的主要特点：

自定义位字段：BITFIELD允许您在 Redis 字符串中的任何位置定义自定义大小的字段。您可以操作跨越不同长度和任意偏移的位。当您需要紧密且高效地打包数据而不遵守标准字节或字大小时，这特别有用。
原子操作：与其他 Redis 操作一样，BITFIELD命令是原子的，这使得它们可以在并发场景中安全使用，而不需要额外的锁定机制。
非字节对齐访问：与对特定字节或对齐位集进行操作的传统位操作不同，BITFIELD它可以对不与字节或字边界对齐的位进行操作，从而在数据结构和存储方式上提供更大的灵活性。
溢出处理：该命令允许为超出其位字段正常容量的操作指定溢出行为。例如，您可以选择环绕、饱和（上限为最大可能值）或在发生溢出时使操作失败。

2. 渐进式遍历

Redis 使用 scan 命令进行渐进式遍历键，进而解决直接使用 keys 获取键时可能出现的阻塞问题。不是一个命令将所有的 key 都拿到，而是每执行一次命令，只获取到其中的一小部分，这样就可以保证当前这一次操作不会太卡。每次 scan 命令的时间复杂度是 O(1)，但是要完整地完成所有键的遍历，需要执行多次 scan。渐进式遍历其实是一组命令，这一组命令的使用方法是一样的。整个过程如下图所示：

scan 命令渐进式遍历：

首次 scan 从 0 开始。
当 scan 返回的下次位置为 0 时，遍历结束。

返回值的前半部分1）是告诉我们，下次继续遍历的光标（当作一个字符串即可）要从哪里开始。第二部分2）是我们真正遍历到的 key 的内容。

scan详解：

以渐进式的方式进行键的遍历。

渐进式遍历再遍历过程中不会在服务器这边存储任何的状态信息，此处的遍历是随时可以终止的，不会对服务器产生任何的副作用。

语法：scan cursor [MATCH pattern] [COUNT count] [TYPE type]

这里的 count 是限制这一次遍历能够获取到多少个元素，默认是 10。

注意：此处的 count（给 Redis 服务器一个 “提示” / “建议”，写入的 count 和实际返回的 key 的个数不一定完全相同，但是不会差很多）和 MySQL 的 limit（精确的）不一样。

命令有效版本：2.8.0 之后

时间复杂度：O(1)

返回值：下一次 scan 的游标（cursor）以及本次得到的键。

示例：

除了 scan 以外，Redis 面向哈希类型、集合类型、有序集合类型分别提供了 hscan、sscan、zscan 命令，它们的用法和 scan 基本类似。

注意：渐进性遍历 scan 虽然解决了阻塞的问题，但如果在遍历期间键有所变化（增加、修改、删除），可能导致遍历时键的重复遍历或者遗漏。

3. 数据库管理

Redis 提供了几个面向 Redis 数据库的操作，分别是命令：dbsize、select、flushdb、flushall。

3.1 切换数据库

select dbIndex

许多关系型数据库，例如 MySQL 支持在一个实例下有多个数据库存在的，但是与关系型数据库用字符来区分不同数据库名不同，Redis 只是用数字作为多个数据库的实现。Redis 默认配置中是有 16 个数据库，我们不能创建新的数据库，也不能删除已有的数据库，这 16 个数据库中的数据是隔离的（相互之间不会有影响）。select 0 操作会切换到第一个数据库，select 15 会切换到最后一个数据库。

0 号数据库和 15 号数据库保存的数据是完全不冲突的，如下图所示，即各种有各自的键值对。默认情况下，我们处于数据库 0。

Redis 管理的数据库：

Redis 中虽然支持多数据库，但随着版本的升级，其实不是特别建议使用多数据库特性。如果真的需要完全隔离的两套键值对，更好的做法是维护多个 Redis 实例，而不是在一个 Redis 实例中维护多数据库。这是因为本身 Redis 并没有为多数据库提供太多的特性，其次无论是否有多个数据库，Redis 都是使用单线程模型，所以彼此之间还是需要排队等待命令的执行。同时多数据库还会让开发、调试和运维工作变得复杂。所以实践中，始终使用数据库 0 其实是一个很好的选择。