Druid-Druid中Router Process

• 基于apache-druid-0.17.0

概述

• Router进程可以被用于查询不同的Broker进程。通常情况下，broker查询路由依赖与规则(Rule)的设定。举例来说，假如最近一个月的数据被加载仅hot cluster，最近一个月内的查询可以路由到一组专用的Broker。查询一个月之外的可以路由到另一组Brokers。这种设置提供了查询隔离，以便对更重要数据的查询不会受到对不太重要数据的查询的影响。
• 如果你的Druid集群达到TB级别，作为使用这仅仅只需要回到查询路由的进程即可。
• 配置文件信息及API信息详见官网；

启动命令

org.apache.druid.cli.Main server router

Router作为管理代理

• 可以将Router配置为将请求转发给活着的Coordinator 或 Overlord 进程。将对集群的HA配置有效。

配置修改

• To enable this functionality, set the following in the Router's runtime.properties:

druid.router.managementProxy.enabled=true

管理代理路由配置

• 管理代理支持隐式和显式路由。隐式路由是那些可以根据Druid API路径约定从原始请求路径确定目标的路由。对于Coordinator来说路径是/druid/ Coordinator /*，对于Overlord来说路径是/druid/indexer/*。这些是方便的，因为它们意味着使用管理代理不需要修改API请求，只需向路由器发出请求，而不是Coordinator或Overlord。大多数Druid API请求可以隐式路由。
• 显式路由是指发送到路由器的请求包含一个路径前缀，该前缀指示请求应该路由到哪个进程。对于Coordinator，这个前缀是/proxy/ Coordinator，对于Overlord，它是/proxy/ Overlord。这对于目标不明确的API调用是必需的。例如，所有的Druid进程都有/status API，所以需要使用显式路由来指示代理目的地。
• 下表叙述如下：
  |Request Route|Destination|Rewritten Route|Example|
  |-------------|-----------|---------------|-------|
  |/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"
}

• 包含此策略意味着所有时间边界查询始终路由到最高优先级的Broker。

priority 优先级

{
  "type":"priority",
  "minPriority":0,
  "maxPriority":1
}

• 将优先级设置为小于minPriority的查询路由到最低优先级的Broker。将优先级设置为大于maxPriority的查询路由到优先级最高的Broker。默认情况下，minPriority是0,maxPriority是1。使用这些默认值，如果发送优先级为0的查询(默认查询优先级为0)，查询将跳过优先级选择逻辑。

Avatica 负载均衡

• 所有具有给定连接ID的Avatica JDBC请求都必须路由到相同的Broker，因为Druid Broker之间不共享连接状态。
• 为此，Druid提供了两个内置的平衡器，分别使用集合哈希和请求连接ID的一致哈希来分配请求给Broker。
• 请注意，当使用多个Router时，所有Router都应该具有相同的平衡器配置，以确保它们做出相同的路由决策。

Rendezvous hash平衡器

• 此平衡器使用Avatica请求的连接ID上的集合散列将请求分配给代理。
• 要使用此平衡器，请指定以下属性:

druid.router.avatica.balancer.type=rendezvousHash

• If no druid.router.avatica.balancer property is set, the Router will also default to using the Rendezvous Hash Balancer.

Consistent hash平衡器

• 这个平衡器对Avatica请求的连接ID使用一致的散列来将请求分配给代理。
• 配置信息如下：

druid.router.avatica.balancer.type=consistentHash

• 这是一个非默认的实现，用于实验目的。一致的hasher在初始化和代理集更改时的设置时间更长，但是在使用5个代理进行测试时，其代理分配时间比会合hasher更快。这两种实现的基准都已经在consistency asherbenchmark和voushasherbenchmark中提供了。一致的hasher也需要锁定，而会合的hasher不需要。