概述
- Router進程可以被用于查詢不同的Broker進程追城。通常情況下郭计，broker查詢路由依賴與規(guī)則(Rule)的設定霞揉。舉例來說有额，假如最近一個月的數(shù)據(jù)被加載僅
hot cluster，最近一個月內的查詢可以路由到一組專用的Broker慕蔚。查詢一個月之外的可以路由到另一組Brokers丐黄。這種設置提供了查詢隔離，以便對更重要數(shù)據(jù)的查詢不會受到對不太重要數(shù)據(jù)的查詢的影響坊萝。
- 如果你的Druid集群達到TB級別，作為使用這僅僅只需要回到查詢路由的進程即可许起。
- 配置文件信息及API信息詳見官網(wǎng)十偶；
啟動命令
org.apache.druid.cli.Main server router
Router作為管理代理
- 可以將Router配置為將請求轉發(fā)給活著的Coordinator 或 Overlord 進程。將對集群的HA配置有效园细。
配置修改
- To enable this functionality, set the following in the Router's runtime.properties:
druid.router.managementProxy.enabled=true
管理代理路由配置
- 管理代理支持隱式和顯式路由惦积。隱式路由是那些可以根據(jù)Druid API路徑約定從原始請求路徑確定目標的路由。對于Coordinator來說路徑是
/druid/ Coordinator /*猛频，對于Overlord來說路徑是/druid/indexer/*狮崩。這些是方便的蛛勉，因為它們意味著使用管理代理不需要修改API請求，只需向路由器發(fā)出請求睦柴，而不是Coordinator或Overlord诽凌。大多數(shù)Druid API請求可以隱式路由。
- 顯式路由是指發(fā)送到路由器的請求包含一個路徑前綴坦敌，該前綴指示請求應該路由到哪個進程侣诵。對于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"
}
- 包含此策略意味著所有時間邊界查詢始終路由到最高優(yōu)先級的Broker稀拐。
priority 優(yōu)先級
{
"type":"priority",
"minPriority":0,
"maxPriority":1
}
- 將優(yōu)先級設置為小于minPriority的查詢路由到最低優(yōu)先級的Broker火邓。將優(yōu)先級設置為大于maxPriority的查詢路由到優(yōu)先級最高的Broker。默認情況下德撬，minPriority是0,maxPriority是1铲咨。使用這些默認值，如果發(fā)送優(yōu)先級為0的查詢(默認查詢優(yōu)先級為0)蜓洪，查詢將跳過優(yōu)先級選擇邏輯纤勒。
Avatica 負載均衡
- 所有具有給定連接ID的Avatica JDBC請求都必須路由到相同的Broker，因為Druid Broker之間不共享連接狀態(tài)隆檀。
- 為此摇天，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
- 這是一個非默認的實現(xiàn)偏形，用于實驗目的。一致的hasher在初始化和代理集更改時的設置時間更長觉鼻，但是在使用5個代理進行測試時俊扭，其代理分配時間比會合hasher更快。這兩種實現(xiàn)的基準都已經在consistency asherbenchmark和voushasherbenchmark中提供了滑凉。一致的hasher也需要鎖定统扳，而會合的hasher不需要。
