在某些特定场景下，由于需要等待线程资源，并行查询会遇到排队等待的情况。本篇博客将介绍如何管理并行执行线程资源，以解决这种问题。
《OceanBase并行执行》系列的内容分为七篇博客，本篇是其中的第三篇。前2篇如下：
| 一 | 并行执行概念 |
| 二 | 如何手动设置并行度 |
3.1 并行执行并发控制
我们利用租户级变量 PARALLEL_SERVERS_TARGET 来设定租户在每个节点上能够提供的最大并行执行工作线程数。在启动并行查询之前，系统会向所有相关的 observer 预约所需的工作线程资源，只有当所有的 observer 都能够为此次并行查询提供足够的资源时，查询才会被投入执行，否则查询将不会启动。该并行查询会被丢回查询队列排队，等待下次执行时重新尝试获取线程资源，直到能获取到足够工作线程资源才能获准执行。整个查询执行完后，预约的工作线程资源会立即释放。
这种“尝试预约工作线程资源-资源不足丢回查询队列-再次获得执行机会-再次尝试预约工作线程资源”的过程我们称之为并行查询排队。管理全部 observer 工作线程资源预约的模块称为并行执行资源管理器。
并行执行资源管理器为了计算每个并行查询需要的工作线程数，会将查询计划做 DFO 划分，模拟调度 DFO 过程，根据 parallel hint、table parallel 等参数计算出该查询在每个 observer 上需要的最大线程数。这组线程数我们称之为“资源向量”。
资源向量是逻辑概念，用于控制并发与排队。使用资源向量从并行执行资源管理器中预约到足够工作线程资源后，并行查询会投入执行。在执行过程中，尽管随着不同 DFO 的调度执行，会不断有物理线程的获取和释放，但是逻辑上的线程资源并不会归还给并行执行资源管理器。只有在并行查询完全执行完成后，这组资源向量才会归还给并行执行资源管理器。
当大量并发查询从并行执行资源管理器预约线程资源时，采取先来先服务的策略，直至资源分配殆尽，无法满足任何一个查询的资源需求为止。之后的查询都会丢回查询队列排队，再次调度时重试获取资源。
3.2 并行执行工作线程分配
在租户的每个 observer 上都有一个并行执行线程池，用于执行并行查询任务。执行任务时，如果线程池里线程数量不足，会动态扩容线程池。如果线程池里的线程空闲时间超过 10 分钟，会触发自动缩容到 10 个线程；如果线程池里的线程空闲时间超过 60 分钟，会触发进一步缩容，可能缩容到 0 个线程。
并行查询一旦获得调度执行后，每个 DFO 总是可以在它涉及到的 observer 的并行执行线程池里获得需要的并行线程资源。需要注意的是，默认情况下，每个 DFO 在一个 observer 上分配的线程数，不得大于租户 MIN CPU * 10，如果它提出的资源需求大于这个值，会被自动降低为 MIN CPU * 10。
3.3 两级资源控制模型
对于任意并行查询，它会经历两级资源控制：
- 全局控制：在执行资源管理器的控制下，预约包含足够执行线程的资源向量
- 局部控制：在并行执行线程池的控制下，分配期望的物理线程数
全局控制会考虑分布式场景下的资源获取，局部控制仅考虑单机线程池的资源分配，二者各司其职。前者确保Query 通过检查后一定能够执行下去，不会在运行时遇到拿不到资源的问题，后者确保极端情况下单个 Query 的 DFO 不会申请远大于能有效利用的物理线程数，造成线程资源浪费。一个并行查询，只要通过了全局控制阶段，就可以顺利执行，无论并发多大，都不会遇到物理线程数不足的问题。
3.4 并行执行资源管理器相关视图
并行执行资源管理器拥有全局视角，通过视图 GV$OB_PX_TARGET_MONITOR能看到租户内每个 observer 的线程预约状态。关于视图字段详细含义，可以参考 ob 官网上的视图手册。
OceanBase(admin@oceanbase)>select * from GV$OB_PX_TARGET_MONITOR;
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
| SVR_IP | SVR_PORT | TENANT_ID | IS_LEADER | VERSION | PEER_IP | PEER_PORT | PEER_TARGET | PEER_TARGET_USED | LOCAL_TARGET_USED | LOCAL_PARALLEL_SESSION_COUNT |
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
| 192.168.11.2 | 19512 | 1004 | N | 555393108309134 | 192.168.11.1 | 19510 | 10 | 6 | 0 | 0 |
| 192.168.11.2 | 19512 | 1004 | N | 555393108309134 | 192.168.11.2 | 19512 | 10 | 0 | 0 | 0 |
| 192.168.11.1 | 19510 | 1004 | Y | 555393108309134 | 192.168.11.1 | 19510 | 10 | 6 | 6 | 1 |
| 192.168.11.1 | 19510 | 1004 | Y | 555393108309134 | 192.168.11.2 | 19512 | 10 | 0 | 0 | 1 |
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
4 rows in set (0.002 sec)在一个瞬态里，不同 observer 看到的全局状态可能不一致，但后台每 500 毫秒就会同步一次全局状态，总体上各个 observer 看到的状态会基本一致，不会有太大偏差。
