phpredis存储时光技巧_Redis实战篇四若安在Redis中保存时间序列数据

UserID, Type, TimeStamp

我之前做过的一个物联网项目的数据存取需求，和这个很相似。
我们须要周期性地统计近万台设备的实时状态，包括设备 ID、压力、温度、湿度，以及对应的韶光戳：

DeviceID, Pressure, Temperature, Humidity, TimeStamp

这些与发生韶光干系的一组数据，便是韶光序列数据。

这些数据的特点是没有严格的关系模型，记录的信息可以表示成键和值的关系（例如，一个设备 ID 对应一条记录），以是，并不须要专门用关系型数据库（例如 MySQL）来保存。
而 Redis 的键值数据模型，恰好可以知足这里的数据存取需求。
Redis 基于自身数据构造以及扩展模块，供应了两种办理方案。

这节课，我就以物联网场景中统计设备状态指标值为例，和你聊聊不同办理方案的做法和优缺陷。

俗话说，“心腹知彼，百战百胜”，我们就先从韶光序列数据的读写特点开始，看看到底该当采取什么样的数据类型来保存吧。

在实际运用中，韶光序列数据常日是持续高并发写入的，例如，须要连续记录数万个设备的实时状态值。
同时，韶光序列数据的写入紧张便是插入新数据，而不是更新一个已存在的数据，也便是说，一个韶光序列数据被记录后常日就不会变了，由于它就代表了一个设备在某个时候的状态值（例如，一个设备在某个时候的温度丈量值，一旦记录下来，这个值本身就不会再变了）。

以是，这种数据的写入特点很大略，便是插入数据快，这就哀求我们选择的数据类型，在进行数据插入时，繁芜度要低，只管即便不要壅塞。
看到这儿，你可能第一韶光会想到用 Redis 的 String、Hash 类型来保存，由于它们的插入繁芜度都是 O(1)，是个不错的选择。
但是，我在第 11 讲中说过，String 类型在记录小数据时（例如刚才例子中的设备温度值），元数据的内存开销比较大，不太适宜保存大量数据。

那我们再看看，韶光序列数据的“读”操作有什么特点。

我们在查询韶光序列数据时，既有对单条记录的查询（例如查询某个设备在某一个时候的运行状态信息，对应的便是这个设备的一条记录），也有对某个韶光范围内的数据的查询（例如每天早上 8 点到 10 点的所有设备的状态信息）。

除此之外，还有一些更繁芜的查询，比如对某个韶光范围内的数据做聚合打算。
这里的聚合打算，便是对符合查询条件的所有数据做打算，包括打算均值、最大 / 最小值、求和等。
例如，我们要打算某个韶光段内的设备压力的最大值，来判断是否有故障发生。

那用一个词概括韶光序列数据的“读”，便是查询模式多。

弄清楚了韶光序列数据的读写特点，接下来我们就看看如何在 Redis 中保存这些数据。
我们来剖析下：针对韶光序列数据的“写要快”，Redis 的高性能写特性直接就可以知足了；而针对“查询模式多”，也便是要支持单点查询、范围查询和聚合打算，Redis 供应了保存韶光序列数据的两种方案，分别可以基于 Hash 和 Sorted Set 实现，以及基于 RedisTimeSeries 模块实现。

接下来，我们先学习下第一种方案。

Hash 和 Sorted Set 组合的办法有一个明显的好处：它们是 Redis 内在的数据类型，代码成熟和性能稳定。
以是，基于这两个数据类型保存韶光序列数据，系统稳定性是可以预期的。

不过，在前面学习的场景中，我们都是利用一个数据类型来存取数据，那么，为什么保存韶光序列数据，要同时利用这两种类型？这是我们要回答的第一个问题。

关于 Hash 类型，我们都知道，它有一个特点是，可以实现对单键的快速查询。
这就知足了韶光序列数据的单键查询需求。
我们可以把韶光戳作为 Hash 凑集的 key，把记录的设备状态值作为 Hash 凑集的 value。

可以看下用 Hash 凑集记录设备的温度值的示意图：

当我们想要查询某个韶光点或者是多个韶光点上的温度数据时，直策应用 HGET 命令或者 HMGET 命令，就可以分别得到 Hash 凑集中的一个 key 和多个 key 的 value 值了。

举个例子。
我们用 HGET 命令查询 202008030905 这个时候的温度值，利用 HMGET 查询 202008030905、202008030907、202008030908 这三个时候的温度值，如下所示：

HGET device:temperature 202008030905"25.1"HMGET device:temperature 202008030905 202008030907 2020080309081) "25.1"2) "25.9"3) "24.9"

你看，用 Hash 类型来实现单键的查询很大略。
但是，Hash 类型有个短板：它并不支持对数据进行范围查询。

虽然韶光序列数据是按韶光递增顺序插入 Hash 凑集中的，但 Hash 类型的底层构造是哈希表，并没有对数据进行有序索引。
以是，如果要对 Hash 类型进行范围查询的话，就须要扫描 Hash 凑集中的所有数据，再把这些数据取回到客户端进行排序，然后，才能在客户端得到所查询范围内的数据。
显然，查询效率很低。

为了能同时支持按韶光戳范围的查询，可以用 Sorted Set 来保存韶光序列数据，由于它能够根据元素的权重分数来排序。
我们可以把韶光戳作为 Sorted Set 凑集的元素分数，把韶光点上记录的数据作为元素本身。

我还是以保存设备温度的韶光序列数据为例，进行阐明。
下图显示了用 Sorted Set 凑集保存的结果。

利用 Sorted Set 保存数据后，我们就可以利用 ZRANGEBYSCORE 命令，按照输入的最大韶光戳和最小韶光戳来查询这个韶光范围内的温度值了。
如下所示，我们来查询一下在 2020 年 8 月 3 日 9 点 7 分到 9 点 10 分间的所有温度值：

ZRANGEBYSCORE device:temperature 202008030907 2020080309101) "25.9"2) "24.9"3) "25.3"4) "25.2"

现在我们知道了，同时利用 Hash 和 Sorted Set，可以知足单个韶光点和一个韶光范围内的数据查询需求了，但是我们又会面临一个新的问题，也便是我们要解答的第二个问题：如何担保写入 Hash 和 Sorted Set 是一个原子性的操作呢？

所谓“原子性的操作”，便是指我们实行多个写命令操作时（例如用 HSET 命令和 ZADD 命令分别把数据写入 Hash 和 Sorted Set），这些命令操作要么全部完成，要么都不完成。

只有担保了写操作的原子性，才能担保同一个韶光序列数据，在 Hash 和 Sorted Set 中，要么都保存了，要么都没保存。
否则，就可能涌现 Hash 凑集中有韶光序列数据，而 Sorted Set 中没有，那么，在进行范围查询时，就没有办法知足查询需求了。

那 Redis 是怎么担保原子性操作的呢？这里就涉及到了 Redis 用来实现大略的事务的 MULTI 和 EXEC 命令。
当多个命令及其参数本身无误时，MULTI 和 EXEC 命令可以担保实行这些命令时的原子性。
关于 Redis 的事务支持和原子性担保的非常情形，我会在第 30 讲中向你先容，这节课，我们只要理解一下 MULTI 和 EXEC 这两个命令的利用方法就行了。

你可以看下下面这张示意图，命令 1 到命令 N 是在 MULTI 命令后、EXEC 命令前发送的，它们会被一起实行，担保原子性。

以保存设备状态信息的需求为例，我们实行下面的代码，把设备在 2020 年 8 月 3 日 9 时 5 分的温度，分别用 HSET 命令和 ZADD 命令写入 Hash 凑集和 Sorted Set 凑集。

127.0.0.1:6379> MULTIOK127.0.0.1:6379> HSET device:temperature 202008030911 26.8QUEUED127.0.0.1:6379> ZADD device:temperature 202008030911 26.8QUEUED127.0.0.1:6379> EXEC1) (integer) 12) (integer) 1

可以看到，首先，Redis 收到了客户端实行的 MULTI 命令。
然后，客户端再实行 HSET 和 ZADD 命令后，Redis 返回的结果为“QUEUED”，表示这两个命令暂时入队，先不实行；实行了 EXEC 命令后，HSET 命令和 ZADD 命令才真正实行，并返回成功结果（结果值为 1）。

到这里，我们就办理了韶光序列数据的单点查询、范围查讯问题，并利用 MUTLI 和 EXEC 命令担保了 Redis 能原子性地把数据保存到 Hash 和 Sorted Set 中。
接下来，我们须要连续办理第三个问题：如何对韶光序列数据进行聚合打算？

聚合打算一样平常被用来周期性地统计韶光窗口内的数据汇总状态，在实时监控与预警等场景下会频繁实行。

由于 Sorted Set 只支持范围查询，无法直接进行聚合打算，以是，我们只能先把韶光范围内的数据取回到客户端，然后在客户端自行完成聚合打算。
这个方法虽然能完成聚合打算，但是会带来一定的潜在风险，也便是大量数据在 Redis 实例和客户端间频繁传输，这会和其他操作命令竞争网络资源，导致其他操作变慢。

在我们这个物联网项目中，就须要每 3 分钟统计一下各个设备的温度状态，一旦设备温度超出了设定的阈值，就要进行报警。
这是一个范例的聚合打算场景，我们可以来看看这个过程中的数据体量。

假设我们须要每 3 分钟打算一次的所有设备各指标的最大值，每个设备每 15 秒记录一个指标值，1 分钟就会记录 4 个值，3 分钟就会有 12 个值。
我们要统计的设备指标数量有 33 个，以是，单个设备每 3 分钟记录的指标数据有将近 400 个（33 12 = 396），而设备总数量有 1 万台，这样一来，每 3 分钟就有将近 400 万条（396 1 万 = 396 万）数据须要在客户端和 Redis 实例间进行传输。

为了避免客户端和 Redis 实例间频繁的大量数据传输，我们可以利用 RedisTimeSeries 来保存韶光序列数据。

RedisTimeSeries 支持直接在 Redis 实例上进行聚合打算。
还是以刚才每 3 分钟算一次最大值为例。
在 Redis 实例上直接聚合打算，那么，对付单个设备的一个指标值来说，每 3 分钟记录的 12 条数据可以聚合打算成一个值，单个设备每 3 分钟也就只有 33 个聚合值须要传输，1 万台设备也只有 33 万条数据。
数据量大约是在客户端做聚合打算的十分之一，很显然，可以减少大量数据传输对 Redis 实例网络的性能影响。

以是，如果我们只须要进行单个韶光点查询或是对某个韶光范围查询的话，适宜利用 Hash 和 Sorted Set 的组合，它们都是 Redis 的内在数据构造，性能好，稳定性高。
但是，如果我们须要进行大量的聚合打算，同时网络带宽条件不是太好时，Hash 和 Sorted Set 的组合就不太适宜了。
此时，利用 RedisTimeSeries 就更加得当一些。

好了，接下来，我们就来详细学习下 RedisTimeSeries。

RedisTimeSeries 是 Redis 的一个扩展模块。
它专门面向韶光序列数据供应了数据类型和访问接口，并且支持在 Redis 实例上直接对数据进行按韶光范围的聚合打算。

由于 RedisTimeSeries 不属于 Redis 的内建功能模块，在利用时，我们须要先把它的源码单独编译成动态链接库 redistimeseries.so，再利用 loadmodule 命令进行加载，如下所示：

loadmodule redistimeseries.so

当用于韶光序列数据存取时，RedisTimeSeries 的操作紧张有 5 个：

下面，我来先容一下如何利用这 5 个操作。

1. 用 TS.CREATE 命令创建一个韶光序列数据凑集

在 TS.CREATE 命令中，我们须要设置韶光序列数据凑集的 key 和数据的过期韶光（以毫秒为单位）。
此外，我们还可以为数据凑集设置标签，来表示数据凑集的属性。

例如，我们实行下面的命令，创建一个 key 为 device:temperature、数据有效期为 600s 的韶光序列数据凑集。
也便是说，这个凑集中的数据创建了 600s 后，就会被自动删除。
末了，我们给这个凑集设置了一个标签属性{device_id:1}，表明这个数据凑集中记录的是属于设备 ID 号为 1 的数据。

TS.CREATE device:temperature RETENTION 600000 LABELS device_id 1OK

2. 用 TS.ADD 命令插入数据，用 TS.GET 命令读取最新数据

我们可以用 TS.ADD 命令往韶光序列凑集中插入数据，包括韶光戳和详细的数值，并利用 TS.GET 命令读取数据凑集中的最新一条数据。

例如，我们实行下列 TS.ADD 命令时，就往 device:temperature 凑集中插入了一条数据，记录的是设备在 2020 年 8 月 3 日 9 时 5 分的设备温度；再实行 TS.GET 命令时，就会把刚刚插入的最新数据读取出来。

TS.ADD device:temperature 1596416700 25.11596416700TS.GET device:temperature25.1

3. 用 TS.MGET 命令按标签过滤查询数据凑集

在保存多个设备的韶光序列数据时，我们常日会把不同设备的数据保存到不同凑集中。
此时，我们就可以利用 TS.MGET 命令，按照标签查询部分凑集中的最新数据。
在利用 TS.CREATE 创建数据凑集时，我们可以给凑集设置标签属性。
当我们进行查询时，就可以在查询条件中对凑集标签属性进行匹配，末了的查询结果里只返回匹配上的凑集中的最新数据。

举个例子。
假设我们一共用 4 个凑集为 4 个设备保存韶光序列数据，设备的 ID 号是 1、2、3、4，我们在创建数据凑集时，把 device_id 设置为每个凑集的标签。
此时，我们就可以利用下列 TS.MGET 命令，以及 FILTER 设置（这个配置项用来设置凑集标签的过滤条件），查询 device_id 不即是 2 的所有其他设备的数据凑集，并返回各自凑集中的最新的一条数据。

TS.MGET FILTER device_id!=21) 1) "device:temperature:1"2) (empty list or set)3) 1) (integer) 15964170002) "25.3"2) 1) "device:temperature:3"2) (empty list or set)3) 1) (integer) 15964170002) "29.5"3) 1) "device:temperature:4"2) (empty list or set)3) 1) (integer) 15964170002) "30.1"

4. 用 TS.RANGE 支持须要聚合打算的范围查询

末了，在对韶光序列数据进行聚合打算时，我们可以利用 TS.RANGE 命令指定要查询的数据的韶光范围，同时用 AGGREGATION 参数指定要实行的聚合打算类型。
RedisTimeSeries 支持的聚合打算类型很丰富，包括求均值（avg）、求最大 / 最小值（max/min），求和（sum）等。

例如，在实行下列命令时，我们就可以按照每 180s 的韶光窗口，对 2020 年 8 月 3 日 9 时 5 分和 2020 年 8 月 3 日 9 时 12 分这段韶光内的数据进行均值打算了。

TS.RANGE device:temperature 1596416700 1596417120 AGGREGATION avg 1800001) 1) (integer) 15964167002) "25.6"2) 1) (integer) 15964168802) "25.8"3) 1) (integer) 15964170602) "26.1"

与利用 Hash 和 Sorted Set 来保存韶光序列数据比较，RedisTimeSeries 是专门为韶光序列数据访问设计的扩展模块，能支持在 Redis 实例上直接进行聚合打算，以及按标签属性过滤查询数据凑集，当我们须要频繁进行聚合打算，以及从大量凑集中筛选出特定设备或用户的数据凑集时，RedisTimeSeries 就可以发挥上风了。

在这节课，我们一起学习了如何用 Redis 保存韶光序列数据。
韶光序列数据的写入特点是要能快速写入，而查询的特点有三个：

关于快速写入的哀求，Redis 的高性能写特性足以应对了；而针对多样化的查询需求，Redis 供应了两种方案。

第一种方案是，组合利用 Redis 内置的 Hash 和 Sorted Set 类型，把数据同时保存在 Hash 凑集和 Sorted Set 凑集中。
这种方案既可以利用 Hash 类型实现对单键的快速查询，还能利用 Sorted Set 实现对范围查询的高效支持，一下子知足了韶光序列数据的两大查询需求。

不过，第一种方案也有两个不敷：一个是，在实行聚合打算时，我们须要把数据读取到客户端再进行聚合，当有大量数据要聚合时，数据传输开销大；另一个是，所有的数据会在两个数据类型中各保存一份，内存开销不小。
不过，我们可以通过设置适当的数据过期韶光，开释内存，减小内存压力。

我们学习的第二种实现方案是利用 RedisTimeSeries 模块。
这是专门为存取韶光序列数据而设计的扩展模块。
和第一种方案比较，RedisTimeSeries 能支持直接在 Redis 实例上进行多种数据聚合打算，避免了大量数据在实例和客户端间传输。
不过，RedisTimeSeries 的底层数据构造利用了链表，它的范围查询的繁芜度是 O(N) 级别的，同时，它的 TS.GET 查询只能返回最新的数据，没有办法像第一种方案的 Hash 类型一样，可以返回任一韶光点的数据。

以是，组合利用 Hash 和 Sorted Set，或者利用 RedisTimeSeries，在支持韶光序列数据存取上各有利害势。
我给你的建议是：