Druid大数据实时处理的开源分布式系统——Broker

第三篇，关于Druid的Broker节点

Broker节点接收来自外部客户端的查询，并将这些查询转发到Realtime和Historical节点。当Broker节点收到结果，它们将合并这些结果并将它们返回给调用者。由于了解拓扑，Broker节点使用Zookeeper来确定哪些Realtime和Historical节点的存在。

Broker 主要完成如下功能：

1. Forwarding Queries

2. Caching

Broker Node是整个集群查询的入口，作为查询路由角色，Broker Node感知Zookeeper上保存的集群内所有已发布的Segment的元信息，即每个Segment保存在哪些存储节点上，Broker Node为Zookeeper中每个dataSource创建一个timeline，timeline按照时间顺序描述了每个Segment的存放位置。我们知道，每个查询请求都会包含dataSource以及interval信息，Broker Node根据这两项信息去查找timeline中所有满足条件的Segment所对应的存储节点，并将查询请求发往对应的节点。

对于每个节点返回的数据，Broker Node默认使用LRU缓存策略；对于集群中存在多个Broker Node的情况，Druid使用memcached共享缓存。对于Historical Node返回的结果，Broker Node认为是“可信的”，会缓存下来，而Real-Time Node返回的实时窗口内的数据，Broker Node认为是可变的，“不可信的”，故不会缓存。所以对每个查询请求，Broker Node都会先查询本地缓存，如果不存在才会去查找timeline，再向相应节点发送查询请求。

Broker节点扮演着Historical Node和Realtime Node的查询路由的角色。Broker节点知道发布于Zookeeper中的关于哪些segment是可查询的和这些segment是保存在哪里的，Broker节点就可以将到来的查询请求路由到正确的Historical Node或者是Realtime Node，Broker节点也会将Historical Node和Realtime Node的局部结果进行合并，然后返回最终的合并后的结果给调用者。

一、缓存

Broker节点包含一个支持 LRU 失效策略的缓存。这个缓存可以使用本地堆内存或者是一个外部的分布式 key/value 存储，例如 Memcached 。每次Broker节点接收到查询请求时，都会先将查询映射到一组segment中去。这一组确定的segment的结果可能已经存在于缓存中，而不需要重新计算。对于那些不存在于缓存的结果，Broker节点会将查询转发到正确的Historical Node和Realtime Node中去，一旦Historical Node返回结果，Broker节点会将这些结果缓存起来以供以后使用，这个过程如图6所示。实时数据永远不会被缓存，因此查询Realtime Node的数据的查询请求总是会被转发到Realtime Node上去。实时数据是不断变化的，因此缓存实时数据是不可靠的。

图. 结果会为每一个segment缓存。查询会合并缓存结果与Historical Node和Realtime Node的计算结果

缓存也可作为数据可用性的附加级别。在所有Historical Node都出现故障的情况下，对于那些命中已经在缓存中缓存了结果的查询，仍然是可以返回查询结果的。

二、可用性

在所有的Zookeeper都中断的情况下，数据仍然是可以查询的。如果Broker节点不可以和Zookeeper进行通信了，它会使用它最后一次得到的整个集群的视图来继续将查询请求转发到Historical Node和Realtime Node，Broker节点假定集群的结构和Zookeeper中断前是一致的。在实践中，在我们诊断Zookeeper的故障的时候，这种可用性模型使得Druid集群可以继续提供查询服务，为我们争取了更多的时间。