长查询问题指的是在数据库写入和查询并存的日常应用场景中，存在处理数据量大且耗时很长的查询长时间占用系统资源，导致写入可能被阻塞的问题。有时，查询代码对于资源释放函数调用的遗忘也可能以长查询问题的形式表现出来。如何在数据写入不被阻塞同时，保证长查询的正确进行是一个具有挑战性的问题。
尽管在绝大多数时序数据使用场景下，用户不太可能遇到这个问题，但一旦出现，也会让人头疼不已。为了解决这一问题，TDengine 研发团队一直致力于不断优化系统，提高查询性能和响应速度。本文将深入剖析这一挑战，并探讨如何应对和解决长查询问题，以提升 TDengine 在复杂查询场景下的表现。
在分析长查询问题之前，我们首先需要为大家普及一下 TDengine 的写入/查询并发机制。
数据写入/读取机制
Vnode 是 TDengine 中存储和查询数据的基本单元，这里主要介绍 Vnode 的写入/读取及并发机制。
数据写入机制
- 每个 Vnode 在创建时都会根据 DB 参数分配一定数量的内存
- 这些内存在 Vnode 中被分为三个内存块
- 每个 Vnode 只有一个线程写入
- Vnode 在写入时，会从内存块的空闲列表 (free list) 中分配一个内存块（mem），供数据写入使用
- 当内存块中数据写入超过一定量后，开始落盘（imem），同时分配一个新的内存块供数据写入使用
- 当内存块全部用完，没有空闲内存块时，写入会被阻塞，一直等待有内存块释放出来
数据查询机制
- 查询分多批次进行，每次返回部分数据，然后该查询等待下一次拉取数据的请求
- 查询结果是内存（mem/imem）数据和硬盘数据合并的结果
- 查询开始时，会先 take snapshot，引用（ref） mem/imem 以及硬盘文件
- 查询结束时，unref mem/imem，如果内存块的引用计数变为 0，则内存块被回收到空闲链表中
长查询问题
时序数据绝大部分查询持续时间都比较短，如查询表/超级表的最后一条记录、做 count 或 sum 类的聚合查询等。这类查询持续时间较短，对于 mem/imem 的占用时间也较短，查询很快会释放 MemTable 供 Vnode 回收再次利用，从而不影响写入的进行。但是，如果存在一个持续时间很长的查询，如超过 1 小时或 1 天的查询，这时候就会出现此类问题。当然，只有一个长查询的情况下，问题也不大，因为 Vnode 的内存池默认被分成了 3 个内存块，一个长查询最多占用两个内存块，还剩余一个内存块可以用来进行持续写入。但是如果存在多个长查询，Vnode 中的所有内存块都可能被长时间占用，无法进行回收，从而导致写入停止的情况。
另外，如果查询部分的代码存在 BUG，忘记关闭查询句柄，也会导致 mem/imem 被长期占用，阻塞写入。这个问题在 TDengine 订阅和流计算功能中曾经就出现过。
长查询问题解决方案
我们需要一个方案，可以在长查询大量存在、或用户应用代码有问题没有及时关闭查询句柄、甚至产品代码有问题的情况下，也能达到既不阻塞写入且不让长查询失败。该方案如下：
- 查询在获取数据快照时，将查询句柄注册到它所占用的内存块上，同时注册一个 reseek 函数
- 当查询结束关闭句柄时，该查询将句柄从它所占用的所有内存块上注销
- 当写入发现没有可用内存块时，尝试回收已经 COMMIT 但是仍旧被查询占用的最老的内存块
- 写入线程回收内存块时，遍历所有注册在该内存块上的注册句柄，调用 reseek 函数
- reseek 函数会尝试锁查询句柄，如果锁句柄成功，则将查询句柄设置为 RESEEK 状态，同时将查询的状态保存下来并 untake snapshot，归还占用的所有内存块
- 查询线程在查询活跃周期开始时锁查询句柄，然后检查是否为 RESEEK 状态，如果为 RESEEK 状态，重新 take snapshot，并根据保存的查询状态，恢复各种查询变量，接着进行查询
从上述方案中我们可以看到：
- 写入在发现内存不足的条件下，可以主动回收非激活状态的查询占用的内存块，从而不会长时间阻塞写入
- 长查询在写入回收其所占用的内存块后，可以根据自己保存的查询状态，重新 take snapshot，继续查询，从而不会让长查询失败
答疑解惑
Q：如何解决死锁问题？
A：在写入回收内存块时，需要遍历查询句柄注册链表，因此需要对链表进行加锁操作，即需要锁定链表的锁。在调用 reseek 回调时，也需要锁定查询句柄的锁。这样就存在写入线程出现 lock(mutex_list)–>lock(mutex_qhandle) 的情况。而在查询结束时，需要将句柄从注册链表中移除，导致出现 lock(mutex_qhandle)–>lock(mutex_list) 的情况。如果两个线程不按照相同的顺序对两个锁进行加锁，就会产生死锁的问题。
为了解决这个问题，可以采用以下优化方案：
- 使用trylock替代lock：对于写入回收调用 reseek 函数的场景，可以尝试使用 trylock 而不是直接使用 lock 来获取查询句柄的控制权。通过 trylock 尝试获取锁，可以避免线程因等待锁而被阻塞，从而减少死锁的风险。
- 多次尝试机制：在使用 trylock 的基础上，可以结合多次尝试的机制。如果一次 trylock 未成功获取锁，可以进行多次尝试，直至成功获取锁或达到尝试次数上限为止。这样能够增加获取锁的机会，降低死锁风险。
Q：长查询会不会一直被写入 reseek，从而导致查询一直恢复？
A：不会存在这种情况。查询在每次打开句柄时，会给一个版本号，这个版本号是已经写入 Vnode 中的最新数据的版本号，查询只能看到版本号小于等于该版本号的数据。当 take snapshot 时，会根据 mem/imem 中的数据是否被查询版本号覆盖而决定 mem/imem 是否被该查询引用。随着数据的写入，新的 mem/imem 中的数据肯定都大于该查询创建时给的版本号，因此，新的 mem/imem 不会被长查询引用。这样一来，一个长查询最多会被写入 RESEEK 两次。
以上就是 TDengine 资深研发人员对解决长查询问题进行的深入探讨。如果你还有关于查询的更多问题想要讨论或交流，可以在下方留言区进行相关评论，静待回复即可~
