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，因此需要使用显式路由来指示代理目标。

汇总如下：

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上的 集合哈希 来将请求分配给Broker。

要使用此平衡器，请指定以下属性：

druid.router.avatica.balancer.type=consistentHash

如果 druid.router.avatica.balancer 配置项没有被设置，Router将同样默认使用集合哈希平衡器。

一致性哈希平衡器

这个平衡器使用Avatica请求的连接ID上的 集合哈希 来将请求分配给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: ```json 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 ```