Broker是Druid中一种类型的节点，在分布式集群部署环境中，它用来路由查询。它能够知晓ZK中存储的关于segment在集群节点分布的meta信息，以便于将查询路由至正确的节点。同时，broker还承担着合并节点查询结果的任务。在启动时，实时节点会向ZK注册自己，并上报其提供服务的segment信息。
启动命令
io.druid.cli.Main server broker
转发查询（Forwarding Queries）
大多数的Druid查询会包含一个interval字段用于指明需要查询的数据时间范围。Druid segment分布于整个集群，它们被分片后存储某些时间段的数据。想象一个简单的datasource，它有7个segment，每个segment包含一个星期中某一天的数据。任何一个查询大于两天数据的查询请求都会定位到多个segment上。这些segment很可能是分布在集群的多个节点上，因此查询也会涉及到对多个节点的请求。
为了确定将查询路由到哪些节点，Broker首先会对ZK中存储的信息做分析汇总。ZK中存储了历史节点、实时节点和他们分别服务的segment信息。针对ZK中存储的每一个datasource，Broker建立了一个segment和服务它们的节点的（时间表）timeline。当接收到一个查询请求时，broker会去时间表中查询包含请求中指定datasource和interval数据的节点信息，从而将请求路由到这些节点上。
缓存
Broker节点维护了一个基于LRU策略的缓存空间，其缓存了每个sgement的数据。它有两种实现方式，一是实现为每个Broker节点的私有本地缓存；而是利用memcached等外部分布式缓存组件实现跨节点缓存共享。Broker每次收到一个请求后，它首先会将其映射到一组segment上面，这组segment的子集的数据有可能已经存在于缓存中，Broker可以直接从缓存中拉取。对于数据不在缓存中的节点，Broker会把请求路由到相应的历史节点上。一旦历史节点返回了查询结果，Broker就会将这些结果数据存储在缓存中。实时节点的segment不会被缓存，因此对于实时数据的查询肯定会被路由到实时节点上，究其理由，实时数据是一直在变动的，所以基于缓存数据的查询是不可靠的。
HTTP Endpoints
Broker为交互暴露了几个HTTP的接口：
GET
- /status
返回Druid的版本信息、加载扩展、使用内存、全部内存和节点的其他有用的信息。 - /druid/v2/datasources
返回可查询的datasource列表 - /druid/v2/datasources/{dataSourceName}
返回指定datasource的维度和指标信息。同时，可以使用可选参数"full",来获取intervals列表和这些interval包含的维度和指标信息。也可以通过"interval"参数来查询确定的某个interval的信息。
如果没有指定interval，将会使用基于当前时间的一个默认interval，它包含当前时刻之前的一段时间。这个interval的长度使用 ISO8601 format格式指定，对应设置参数为：druid.query.segmentMetadata.defaultHistory - /druid/v2/datasources/{dataSourceName}/dimensions
返回这个datasource的维度 - /druid/v2/datasources/{dataSourceName}/metrics
返回这个datasource的指标 - /druid/v2/datasources/{dataSourceName}/candidates?intervals={comma-separated-intervals-in-ISO8601-format}&numCandidates={numCandidates}
根据给定的datasource和intervals，返回segment列表和所在的节点信息。如果"numCandidates"未指定，将会返回每个interval包含的segment所在的所有节点信息。 - /druid/broker/v1/loadstatus
返回一个标志，指明Broker是否获取了ZK中所有segment的信息。通过这个接口可以知道在比如重启的场景下，Broker是否能接受查询请求。
POST
- /druid/v2/candidates/
根据指定的查询，返回包含服务地址的segment信息列表。
