router part

This commit is contained in:
liujianhuan 2020-04-07 13:29:40 +08:00
parent eb0e10054d
commit 2d27cef93c
1 changed files with 162 additions and 1 deletions

View File

@ -1 +1,162 @@
<!-- toc --> <!-- toc -->
### Router
> [!WARNING]
> Router是一个可选的和实验性的特性因为它在Druid集群架构中的推荐位置仍在不断发展。然而它已经在生产中经过了测试并且承载了强大的Druid控制台所以您应该放心地部署它。
Apache Druid Router用于将查询路由到不同的Broker。默认情况下Broker根据 [规则]() 设置路由查询。例如如果将最近1个月的数据加载到一个 `热集群`则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
出于查询路由的目的如果您有一个TB数据规模的Druid集群您应该只使用Router进程。
除了查询路由Router还运行 [Druid控制台](), 一个用于数据源、段、任务、数据进程Historical和MiddleManager和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
### 配置
对于Apache Druid Router的配置请参见 [Router 配置]()
### HTTP
对于Router的API列表请参见 [Router API]()
### 运行
```
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
```