162 lines
7.8 KiB
Markdown
162 lines
7.8 KiB
Markdown
<!-- toc -->
|
||
### Router
|
||
|
||
> [!WARNING]
|
||
> Router是一个可选的和实验性的特性，因为它在Druid集群架构中的推荐位置仍在不断发展。然而，它已经在生产中经过了测试，并且承载了强大的Druid控制台，所以您应该放心地部署它。
|
||
|
||
Apache Druid Router用于将查询路由到不同的Broker。默认情况下，Broker根据 [规则](../Operations/retainingOrDropData.md) 设置路由查询。例如，如果将最近1个月的数据加载到一个 `热集群` 中，则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离，以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
|
||
|
||
出于查询路由的目的，如果您有一个TB数据规模的Druid集群，您应该只使用Router进程。
|
||
|
||
除了查询路由，Router还运行 [Druid控制台](../Operations/manageui.md), 一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||
|
||
### 配置
|
||
|
||
对于Apache Druid Router的配置，请参见 [Router 配置](../Configuration/configuration.md#Router)
|
||
|
||
### HTTP
|
||
|
||
对于Router的API列表，请参见 [Router API](../Operations/api.md#Router)
|
||
|
||
### 运行
|
||
|
||
```
|
||
org.apache.druid.cli.Main server router
|
||
```
|
||
|
||
### 作为管理代理的Router
|
||
|
||
Router可以配置为将转发请求到活跃的Coordinator和Overlord。 该功能在非活跃 -> 活跃的Coordinator和Overlord的HTTP重定向机制无法正常工作时的情况下(服务器位于负载平衡器后面，重定向中使用的主机名只能在内部解析等)设置高可用集群很有帮助。
|
||
|
||
**开启管理代理**
|
||
|
||
要启用此功能，请在Router的 `runtime.properties` 中设置以下内容：
|
||
|
||
```
|
||
druid.router.managementProxy.enabled=true
|
||
```
|
||
|
||
**管理代理路由**
|
||
|
||
管理代理支持隐式和显式路由。隐式路由是根据Druid API路径从原始请求路径来确定目标的路由。对于Coordinator，约定是 `/druid/Coordinator/*`。 对于Overlord，约定是 `/druid/indexer/*`。由于使用管理代理不需要修改API请求，只需要向Router而不是Coordinator或Overlord发出请求，所以是非常方便的。大多数Druid API请求都可以隐式路由。
|
||
|
||
显式路由是指到Router的请求包含路径前缀的路由，该前缀指示请求应路由到哪个进程。对于Coordinator，这个前缀是 `/proxy/coordinator`；对于Overlord，这个前缀是 `/proxy/overlord`。这对于目标不明确的API调用是必需的, 例如，所有Druid进程上都存在 `/status` API，因此需要使用显式路由来指示代理目标。
|
||
|
||
汇总如下：
|
||
|
||
| 请求路由 | 目标 | 重写路由 | 示例 |
|
||
| - | - | - | - |
|
||
| `/druid/coordinator/*` | Coordinator | `/druid/coordinator/*` | `router:8888/druid/coordinator/v1/datasources` -> `coordinator:8081/druid/coordinator/v1/datasources` |
|
||
| `/druid/indexer/*` | Overlord | `/druid/indexer/*` | `router:8888/druid/indexer/v1/task` -> `overlord:8090/druid/indexer/v1/task`|
|
||
| `/proxy/coordinator/*` | Coordinator | `/*` | `router:8888/proxy/coordinator/status` -> `coordinator:8081/status` |
|
||
| `/proxy/overlord/*` | Overlord | `/*` | `router:8888/proxy/overlord/druid/indexer/v1/isLeader` -> `overlord:8090/druid/indexer/v1/isLeader` |
|
||
|
||
### Router策略
|
||
Router有一个可配置的策略列表，用于选择将查询路由到哪个Broker。策略的顺序很重要，因为一旦策略条件匹配，就会选择一个Broker。
|
||
|
||
**timeBoundary**
|
||
```
|
||
{
|
||
"type":"timeBoundary"
|
||
}
|
||
```
|
||
|
||
包含这个策略的话意味着所有的 **timeRange** 查询将全部路由到高优先级的Broker
|
||
|
||
**priority**
|
||
```
|
||
{
|
||
"type":"priority",
|
||
"minPriority":0,
|
||
"maxPriority":1
|
||
}
|
||
```
|
||
|
||
优先级设置为小于 `minPriority` 的查询将路由到最低优先级Broker, 优先级设置为大于 `maxPriority` 的查询将路由到最高优先级Broker。默认情况下，`minPriority` 为0，`maxPriority` 为1。使用这些默认值的时候，如果发送优先级为0（默认查询优先级为0）的查询，则查询将跳过优先级选择逻辑。
|
||
|
||
**JavaScript**
|
||
允许使用JavaScript函数定义任意路由规则。将配置和要执行的查询传递给函数，并返回它应该路由到的层（tier），或者对于默认层返回null。
|
||
|
||
示例：将包含三个以上聚合器的查询发送到最低优先级Broker的函数：
|
||
```
|
||
{
|
||
"type" : "javascript",
|
||
"function" : "function (config, query) { if (query.getAggregatorSpecs && query.getAggregatorSpecs().size() >= 3) { var size = config.getTierToBrokerMap().values().size(); if (size > 0) { return config.getTierToBrokerMap().values().toArray()[size-1] } else { return config.getDefaultBrokerServiceName() } } else { return null } }"
|
||
}
|
||
```
|
||
|
||
> [!WARNING]
|
||
> 默认情况下禁用基于JavaScript的功能。有关使用Druid的JavaScript功能的指南，包括如何启用它的说明，请参阅[Druid JavaScript编程指南]()。
|
||
|
||
### Avatica查询平衡
|
||
|
||
具有给定连接ID的所有Avatica JDBC请求都必须路由到同一个Broker，因为Druid Broker之间不共享连接状态。
|
||
|
||
为了实现这一点，Druid提供了两个内置的平衡器，它们分别使用请求的连接ID的集合哈希和一致性哈希来将请求分配给Broker。
|
||
|
||
请注意，当使用多个Router时，所有Router应具有相同的平衡器配置，以确保它们做出相同的路由决策。
|
||
|
||
**集合哈希平衡器**
|
||
|
||
这个平衡器使用Avatica请求的连接ID上的 [集合哈希](https://en.wikipedia.org/wiki/Rendezvous_hashing) 来将请求分配给Broker。
|
||
|
||
要使用此平衡器，请指定以下属性：
|
||
```
|
||
druid.router.avatica.balancer.type=consistentHash
|
||
```
|
||
如果 `druid.router.avatica.balancer` 配置项没有被设置，Router将同样默认使用集合哈希平衡器。
|
||
|
||
**一致性哈希平衡器**
|
||
|
||
这个平衡器使用Avatica请求的连接ID上的 [集合哈希](https://en.wikipedia.org/wiki/Consistent_hashing) 来将请求分配给Broker。
|
||
|
||
要使用此平衡器，请指定以下属性：
|
||
```
|
||
druid.router.avatica.balancer.type=consistentHash
|
||
```
|
||
这是为实验目的而提供的非默认实现。一致哈希器在初始化和Brokers更改时的设置时间较长，但在使用5个Broker进行测试时，它的Broker分配时间比集合哈希器快。这两种实现的基准已经在 `ConsistentHasherBenchmark` 和 `RendezvousHasherBenchmark` 中提供。一致哈希器还需要锁定，而集合哈希器不需要。
|
||
|
||
### 生产环境配置示例
|
||
|
||
在本例中，我们的生产集群中有两个层：`hot`层和 `默认层(_default_tier)`。对 `hot` 层的查询通过 `broker-hot` 路由，对 `默认层` 的查询通过 `broker-cold` 路由。如果发生任何异常或网络问题，查询将被路由到 `broker-cold`。在我们的示例中，我们运行的是一个c3.2xlarge EC2实例。我们假设 `common.runtime.properties` 已经存在。
|
||
|
||
JVM设置：
|
||
|
||
```
|
||
-server
|
||
-Xmx13g
|
||
-Xms13g
|
||
-XX:NewSize=256m
|
||
-XX:MaxNewSize=256m
|
||
-XX:+UseConcMarkSweepGC
|
||
-XX:+PrintGCDetails
|
||
-XX:+PrintGCTimeStamps
|
||
-XX:+UseLargePages
|
||
-XX:+HeapDumpOnOutOfMemoryError
|
||
-XX:HeapDumpPath=/mnt/galaxy/deploy/current/
|
||
-Duser.timezone=UTC
|
||
-Dfile.encoding=UTF-8
|
||
-Djava.io.tmpdir=/mnt/tmp
|
||
|
||
-Dcom.sun.management.jmxremote.port=17071
|
||
-Dcom.sun.management.jmxremote.authenticate=false
|
||
-Dcom.sun.management.jmxremote.ssl=false
|
||
```
|
||
|
||
Runtime.properties:
|
||
```
|
||
druid.host=#{IP_ADDR}:8080
|
||
druid.plaintextPort=8080
|
||
druid.service=druid/router
|
||
|
||
druid.router.defaultBrokerServiceName=druid:broker-cold
|
||
druid.router.coordinatorServiceName=druid:coordinator
|
||
druid.router.tierToBrokerMap={"hot":"druid:broker-hot","_default_tier":"druid:broker-cold"}
|
||
druid.router.http.numConnections=50
|
||
druid.router.http.readTimeout=PT5M
|
||
|
||
# Number of threads used by the Router proxy http client
|
||
druid.router.http.numMaxThreads=100
|
||
|
||
druid.server.http.numThreads=100
|
||
``` |