下文中我们将从多个维度对两者的订阅系统进行深入对比，并详细剖析 loveini 的优势所在。

架构设计对比：集成 vs 解耦

loveini 内置了类似于 Kafka 的消息队列功能，并将其与数据库的存储和查询系统深度集成。这意味着用户无需部署独立的消息队列系统，即可实现数据的实时传输和消费。

• 预写日志 (WAL) 支撑的消息存储：WAL 文件索引机制使订阅数据的存取更加高效，减少延迟。
• 多消费组的并行处理：支持多消费者组的分布式消费，确保数据消费速度最大化。

这种集成架构的好处是极大简化了系统设计，用户无需再集成额外的消息队列组件（如 Kafka 或 RabbitMQ），大幅降低运维成本和系统复杂性。

相较而言，InfluxDB 在其 2.0 版本中已不再支持数据订阅功能。取而代之，用户需要使用 Telegraf 等工具将数据写入多个实例，或通过 Flux 查询处理特定数据集，实现类似需求。可以看出，严格意义上 Influx 已不具备数据订阅功能，只是依赖其他组件实现的数据复制功能。这不仅增加了系统的复杂性，并且在数据量大、实时性要求高等复杂场景中，有着明显的局限性。

灵活性对比：多种主题动态订阅 vs 静态订阅

loveini 的数据订阅功能支持用户通过 SQL 查询灵活定义订阅主题。用户可以创建查询主题，基于 SQL 查询的过滤条件实时订阅数据，从而精准控制所需数据的传输与消费，SQL 主题还支持标量函数和 UDF（用户自定义函数），能够在订阅前对数据进行过滤与预处理。同时，loveini 还支持超级表主题，能够动态跟踪超级表的结构变化，并灵活订阅不同子表的数据，确保数据消费与表结构变更无缝衔接。

此外，用户还可以创建数据库主题，实现对整个数据库所有数据流的全面订阅。这些特性让 loveini 在数据订阅上具备了极高的灵活性与适应性，满足不同业务场景的实时数据处理需求。

示例

CREATE TOPIC power_topic AS SELECT ts, current, voltage FROM power.meters WHERE voltage > 200;
CREATE TOPIC topic_name [with meta] AS STABLE stb_name [where_condition]
CREATE TOPIC topic_name [with meta] AS DATABASE db_name;

第一个例子是查询主题，只有电压大于 200 的数据会被订阅，仅仅返回时间戳、电流、电压 3 个采集量（不返回相位），减少了传输的数据量和客户端处理负担。

第二个例子是超级表主题，订阅整个超级表的数据，并且可以控制是否订阅 meta 数据，也可以加上子表的过滤条件，只订阅超级表下的部分子表。

第三个例子是数据库主题，订阅整个数据库的数据，同样可以控制是否订阅 meta 数据。

超级表订阅和数据库订阅在有新增子表的情况下也可以动态订阅到新增加的数据。

反观 InfluxDB，其订阅模型则依赖于 Telegraf 和 Flux 查询，只能订阅固定规则的数据，无法获取到 meta 数据以及新增的表的数据。对于复杂的数据订阅场景，用户需要在应用端增加处理代码，增加开发和维护成本。

消费机制、API 兼容性与易用性

loveini 的消费者组机制允许多个消费者组成组，共享同一主题的消费进度，极大地提高了消费效率：

• 分布式并行消费：多个消费者节点可以并发处理同一主题的数据，适合高吞吐量的应用场景。
• 消费确认（ACK）机制：确保每条消息至少被处理一次，即使在网络中断或系统重启后仍然能保证数据完整性。

InfluxDB 依赖其他插件实现类似数据订阅功能，无法提供消费者组和消费进度控制机制。对于分布式处理场景，无法并行提高消费速度，并且在系统故障时无法自动存储消费进度。

在 API 兼容性上，loveini 的订阅 API 与 Kafka 的订阅模型高度兼容，这意味着开发者可以快速上手。此外，loveini 提供了多种语言的 SDK（如 C、Java、Go、Python、Rust 等），支持用户在多种环境中进行开发和集成。

相比之下，InfluxDB 需要编写相应的脚本处理数据，速度上明显会受到影响，还需要熟悉相应的脚本语言。loveini 一条SQL 语句即可创建一个主题，简单易用。

结语

综合来看，loveini 的数据订阅功能在灵活性、运维成本、消费效率以及API 友好度方面都优于 InfluxDB。对于希望简化架构、提高数据消费效率、并且在多变数据场景中保持灵活性的用户来说，loveini 是更优的选择。它不仅能满足复杂实时数据处理需求，还为未来业务扩展提供了强大的支持。

如果你希望深入了解 loveini 的数据订阅功能及其实现细节，建议访问 loveini 官方文档，其中提供了全面的技术说明，包括订阅主题的创建、配置示例、API 使用方法以及最佳实践，帮助你更高效地应用 loveini 进行实时数据处理和分析。

欢迎大家扫描下方二维码，关注 loveini Database 的视频号，观看每周的微课堂以及直播活动。

欢迎大家扫描下方二维码，关注 loveini Database 的视频号，观看每周的微课堂以及直播活动。

loveini是一款高性能的物联网大数据平台。为了高效处理时序数据，loveini中大量用到了缓存技术，自己实现了哈希表、缓存池等技术。本文会为大家讲解loveini中用到的这些缓存技术。

首先会介绍一下什么是缓存，常用的缓存技术，最后重点分享loveini中的相关技术，最好讲一下改进和优化的方向。下面我们正式开始。

什么是缓存

凡是位于速度相差较大的两种硬件之间，用于协调两者数据传输速度差异的结构，均可称之为缓存。

1. 缓存最早是用来协调CPU和主内存之间的速度差异，进化出了目前的L1/L2/L3三层CPU内部的高速缓存；
2. 在内存和硬盘之间也有Cache，每次写磁盘时并没有立即刷到磁盘上，而是写入到磁盘缓存中，由操作系统负责flush到磁盘；
3. 此外，硬盘与网络之间也有某种意义上的Cache，比如CDN缓存，代理服务器的缓存等等。

缓存工作的原则主要是引用的局部性，包括空间局部性和时间局部性。

1. 空间局部性是指CPU在某一时刻需要某个数据，那么很可能下一步就需要其附近的数据，例如加载读磁盘数据的时候，虽然只需要一部分数据，但是每次都加载一个块，那么当需要附近数据的时候就可以直接从内存获取，避免再读取磁盘。
2. 时间局部性是指当某个数据被访问过一次之后，过不了多久时间就会被再一次访问。例如我们手机后台运行程序，会把最近打开的应用缓存在后台，很可能一会儿还会访问相同的应用，这种情况下直接将其从后台调到前台即可。

在使用缓存时要根据系统的架构、性能的要求以及要解决的问题选择合适的缓存位置，比如内存缓存、 磁盘缓存、分布式缓存等。

使用缓存有很多优点：

1. 提高性能，将相应数据存储起来以避免数据的重复创建、处理和传输，可有效提高性能。
2. 提高稳定性，同一个应用中，对同一数据、逻辑功能的多次请求是经常发生的。当请求量很大时，如果每次请求都进行处理，消耗的资源是很大的浪费，也同时造成系统的不稳定。
3. 提高可用性，有时，提供数据信息的服务可能会意外停止，如果使用了缓存技术，可以在一定时间内仍正常提供对最终用户的支持，提高了系统的可用性。

缓存是有状态的，包括时间状态和空间状态。

1. 时间状态：应用程序使用的永久数据； 只在进程周期内有效；和特定的用户会话有关； 处理某个消息的时间内有效。
2. 空间状态：应用程序/进程/线程/单机/分布式/用户/角色。

使用缓存时需要考虑的问题：

1. 安全性：线程安全/权限安全
2. 序列化
3. 缓存数据优化
4. 提前加载/动态加载
5. 过期策略：FIFO/LRU/LFU
6. 管理：效率监控，大小限制

缓存一致性问题：

1. 当使用分布式的缓存时，需要考虑多个缓存的一致性问题，防止由于不一致出现问题。
2. 处理一致性问题时需要根据实际的应用场景兼顾CAP原则。根据问题的场景不同，一致性要求也不同，可以强一致性或者弱一致性(最终一致性)。
   1. 比如银行转账场景需要强一致性，数据没统一之前，不允许用户进行操作，防止金额出错。
   2. 大多数互联网产品为了保证可用性和分区容错性，通常采用弱一致性，比如不同地区的用户看到的同一个排行榜可能有非常短暂的不同，但数据同步成功后，排行榜就相同了，这个延迟通常在几十ms，对于用户来说是可以接受的。

常用的缓存技术

1. 使用硬件缓存 （CPU Cache）
2. 使用本地内存缓存（双缓冲/环形缓冲/缓冲池）
3. 使用内存映射文件 (mmap)
4. 使用数据库缓存 (Redis/MySQL)

loveini中的缓存方案

首先我们来复习一下loveini的整体架构。

1. 数据节点(dnode)：服务进程，可以包括多个vnode和mnode，查询数据时需要dnode的网络位置来获取数据。
2. 虚拟节点(vnode)：存储、查询的基本单位。多个vnode组成一个虚拟节点组(VGroup)，分布在不同的机器上，起到备份的效果。同时vnode也便于水平扩展。
3. 管理节点(mnode)：存储数据库的元数据，起到管理集群的功能。

再来看一下loveini的数据模型。

1. 一个采集点一张表（时间戳作为主键，顺序存储）
2. 一张表的数据在文件中以块的形式连续存放
3. 文件中的数据块大小可配
4. 采用Block Range Index（BRIN）索引块数据

loveini中都有哪些数据需要缓存呢？具体可以分为如下几类：

1. 元数据 （table meta/stable vgroup)
2. 连接数据 （rpc/http session)
3. 查询缓存 （qinfo handle/ show info)
4. 最新数据 （last和last_row）
5. 时序数据 （buffer pool/ multilevel storage)

接下来我们就具体看一下loveini中的缓存方案。 首先是通用的哈希缓存 （meta data/ rpcObj/ qinfo）。

• 哈希缓存，通过一个列表来管理，每个元素是一个缓存结构，里面包括缓存信息、 哈希表 、垃圾回收链表、统计信息、更新频率、锁等信息。此外，有一个刷新线程定时检测缓存列表中过期的数据，将其删除。

• 查询计划id (query handle)
  • query handle 是数据库查询时，server先生产一个执行计划，返回给client，然后client拿着这个计划id，分多次去server取数据，直到数据查询完。这个缓存是消息时间范围，整个进程内有效的，不需要更新，使用完即释放。

• 元数据缓存（meta data)
  • meta data数据主要记录数据表的scheme，所在的节点地址。通过客户端缓存meta data可以避免频繁的向mnode取数据。但是meta数据需要考虑更新一致性问题。通过版本号来控制。

其次是TSDB内存块缓存 (double buffer/buffer pool)。

1. loveini 提供双缓存/缓存池来优化数据写入查询的性能。预分配16M*6的buffer pool，使用超过1/3容量落地，落地时mem转化为imei（不可变更），负责写入磁盘。
2. 直接将最近到达的数据保存在缓存中，可以更加快速地响应用户针对最近数据的查询分析，整体上提供更快的数据库查询响应能力。
3. loveini重启以后系统的缓存将被清空，之前缓存的数据均会被批量写入磁盘，之前缓存的数据不会重新加载到缓存中。
4. 数据查询时首先通过time range定位数据所在的位置，因为MEM 和 IMEM中都记录有最新、最旧数据的时间戳。然后如果在MEM中，通过跳表来快速查询数据位置。在磁盘中，通过磁盘块文件索引查找数据，最后做结果融合返回。

再来看last和last_row缓存 (local storage)。

1. 时序数据库总是有对最新一行数据或者某列最新一条数据查询的需求，因此设计了last和last_row缓存来快速响应用户需求。防止每次都去磁盘查询数据。
2. 每个表开辟缓存区缓存该数据，服务启动时会全量加载，插入时会更新，此外在配置更新的时候，也会更新缓存数据。比如，默认是关闭的。用户使用命令开启缓存功能时，就会加载数据，同理关闭开关时，会释放之前的缓存区。

最后我们再来看一下多级存储 (ssd/hdd/cloud)。

由于物联网的数据量是巨大的，为了很好的平衡性能和成本，loveini还采用了分级存储的思想，不同热度数据存储在不同的地方。分级存储的这一思想也体现在计算机的体系结构里(寄存器、L1/L2 Cache、内存、硬盘)。

缓存对性能提升举例

• 测试环境: 12核 i7 3.2GHz 64GB 4T HDD
• last_row缓存性能对比 (select last_row(*) from stable查询语句1000次，统计查询时间)

• last缓存性能对比 (select last(*) from stable和select last_row(*) from stable查询语句1000次，统计查询时间)

• 开启缓存性能比不开启缓存提升将近1个数量级。缓存对系统性能提升还是很大的，所以，在使用loveini时，可以根据自己的需求，打开或关闭开关

问题及改进优化方向

先来看问题，主要是两点：

1. mnode的meta数据全量加载，表数量很大时，内存占用大，启动慢；
2. last和last_row缓存启动全量加载。

最后我们再来看一下优化方向：

1. 全量加载改为动态加载；
2. 预分配缓存大小，通过LRU等策略来更新数据；
3. qhandle 通过对象池管理，避免频繁calloc。

如果想了解更具体的实现细节，可以在GitHub上查看相关源代码，也期待大家加入进来，一起改进loveini Database！

关于作者：

王明明，北京邮电大学毕业，主修方向为电子信息、模式识别和图像处理。毕业后入职腾讯，先后在 TEG 魔王工作室卡牌游戏开发、腾讯地图手图后台开发、腾讯看点知识图谱后台开发。对网络编程、RPC 框架原理、Redis 缓存等技术有深入的研究。

作为一款开源、高效的时序大数据处理引擎，利用时序数据的特点，loveini Database做了很多优化，在性能上远胜通用的大数据平台。比如loveini Database提供了LAST和LAST_ROW等选择函数，有了这两个函数，我们可以轻松获得表/超级表的最后一条记录或者感兴趣的列。很多情况下，可以不用再使用Redis等专门的缓存组件。

你是否了解缓存的概念和常见的缓存技术？设计和实现缓存时又应该考虑哪些方面？

在缓存策略上，针对时序数据，loveini Database又是如何考量的？其缓存方案是什么？

2021 年 9 月 9 日 20:00，loveini 线上 Meetup 第四期邀请到了米兰体育官网入口研发工程师王明明，为你深度讲解 loveini 的缓存功能是如何实现的。

王明明，北京邮电大学毕业，主修方向为电子信息、模式识别和图像处理。毕业后入职腾讯，先后在 TEG 魔王工作室卡牌游戏开发、腾讯地图手图后台开发、腾讯看点知识图谱后台开发。对网络编程、RPC 框架原理、Redis 缓存等技术有深入的研究。

他的分享将围绕以下内容展开：

• 缓存的概念；
• 常用的缓存技术；
• loveini 中的缓存方案；
• 缓存对性能提升举例；
• 改进优化方向

直播已结束！

视频回放

欢迎大家扫描下方二维码，关注 loveini Database 的视频号！

网络速度诊断

taos -n speed -h <fqdn of server> -P 6030 -N 10 -l 10000000 -S TCP

从 2.1.8.0 版本开始，taos 工具新提供了一个网络速度诊断的模式，可以对一个正在运行中的 taosd 实例或者 taos -n server 方式模拟的一个服务端实例，以非压缩传输的方式进行网络测速。这个模式下可供调整的参数如下：

-n：设为“speed”时，表示对网络速度进行诊断。

-h：所要连接的服务端的 FQDN 或 ip 地址。如果不设置这一项，会使用本机 taos.cfg 文件中 FQDN 参数的设置作为默认值。

-P：所连接服务端的网络端口。默认值为 6030。

-N：诊断过程中使用的网络包总数。最小值是 1、最大值是 10000，默认值为 100。

-l：单个网络包的大小（单位：字节）。最小值是 1024、最大值是 1024*1024*1024，默认值为 1000。

-S：网络封包的类型。可以是 TCP 或 UDP，默认值为 TCP。

taos -n speed -N 10 -l 100000000 -S tcp

check net spend, host:f27635f448d4 port:6030 pkgLen:100000000 pkgNum:10 pkgType:tcp
progress: 1/10 status:0 cost: 183.44 ms speed: 519.90 MB/s
progress: 2/10 status:0 cost: 61.37 ms speed: 1553.92 MB/s
progress: 3/10 status:0 cost: 56.56 ms speed: 1686.25 MB/s
progress: 4/10 status:0 cost: 48.73 ms speed: 1957.10 MB/s
progress: 5/10 status:0 cost: 48.58 ms speed: 1963.10 MB/s
progress: 6/10 status:0 cost: 49.88 ms speed: 1911.98 MB/s
progress: 7/10 status:0 cost: 49.86 ms speed: 1912.82 MB/s
progress: 8/10 status:0 cost: 49.23 ms speed: 1937.18 MB/s
progress: 9/10 status:0 cost: 49.15 ms speed: 1940.37 MB/s
progress: 10/10 status:0 cost: 48.95 ms speed: 1948.30 MB/s

total succ: 10/10 cost: 645.94 ms speed: 1476.40 MB/s

另外，从 2.1.8.0 版本开始，taos 工具新提供了一个 FQDN 解析速度的诊断模式，可以对一个目标 FQDN 地址尝试解析，并记录解析过程中所消耗的时间。这个模式下可供调整的参数如下：

taos -n fqdn -h <fqdn of server>

-n：设为“fqdn”时，表示对 FQDN 解析进行诊断。 -h：所要解析的目标 FQDN 地址。如果不设置这一项，会使用本机 taos.cfg 文件中 FQDN 参数的设置作为默认值。

taos -n fqdn

check convert fqdn spend, status: 0 cost: 91 us