我们已经看到了光。
在与 Fangjin 和 Giam 进行了一次精彩的会面之后，我们正沿着 Tranquility 路线前进，以便从 Kinesis 到 Druid 进行实时摄取。对我来说，这意味着熟悉 Druid 集群中扩展的节点类型集。
要适应集群和新的节点类型，没有比启动一个完整的环境并试一试更好的方法了。没有比“ vagrant up ”更好的方法了！
因此，今天早上我着手创建一个适合 Tranquility 的完整环境，其中包括中层管理人员（通常从独立的“简单”集群中省略）。我从 Quantily 的 Druid 0.6.160 流浪者配置 开始，分叉回购协议，然后开始工作。
如果你不耐烦，你可以 在这里找到我的叉子 然后开始。如果你有耐心...
了解 Druid 集群的结构很重要。首先，Druid 依赖于 Zookeeper 和 MySQL。 install.sh 脚本 安装这些的普通版本，并在 MySQL 中创建一个德鲁伊数据库和用户。 （德鲁伊本身在启动时填充模式。）
以下是 Druid 集群中的服务器类型列表。在我们的 vagrant 服务器上，每个服务器占用不同的端口，并有自己的配置。 （下面还有详细介绍）
霸王：（8080端口）
overlord负责Druid集群上的任务管理。由于 Tranquility 主要是一个编排引擎，实时分配任务以创建片段，因此 overlord 是 Tranquility 进入 Druid 集群的入口点。
https://github.com/boneill42/druid-vagrant/blob/master/config/overlord/runtime.properties
协调员：（端口8081）
协调器负责段管理，告诉节点加载/删除段。
https://github.com/boneill42/druid-vagrant/blob/master/config/coordinator/runtime.properties
经纪人：（端口8090）
Broker 是系统中的查询代理。它接收查询，知道哪些节点有哪些段，并将查询代理到相应的节点。
https://github.com/boneill42/druid-vagrant/blob/master/config/broker/runtime.properties
历史：（端口 8082）
历史节点是加载段和响应“静态”数据查询的野兽。一旦一个段被提交到深度存储，它就会被一个历史节点加载，它会响应查询。
https://github.com/boneill42/druid-vagrant/blob/master/config/historical/runtime.properties
中间管理器：（端口 8100）
MiddleManagers 正是这样。 =) 他们将任务推送到他们在同一节点上产生的 Peons。现在，一个 Peon 从事一项任务，即产生一个片段。 （可能会改变）
https://github.com/boneill42/druid-vagrant/blob/master/config/middleManager/runtime.properties
关于实时节点的特别说明：
根据我之前的博客 ，我们正在讨论实时 (RT) 节点的使用。但是有了 Tranquility，您就不需要 RT 节点了。它们被临时的 peon 实例所取代，这些实例运行一个临时的 firehose，直接从 Tranquility 客户端获取该段的事件。
Druid 的目标是高可用性、完全复制的、事务性的实时摄取。由于 RT 节点不共享任何内容。他们无法协调也无法复制数据，这意味着他们不适合项目的战略愿景。 Tranquility 及其协调的摄取模型最终可能会完全淘汰/替换 RT 节点。 （有关更多信息，请参见 #1642 ）
入门
好的——言归正传。
要启动您自己的集群，只需克隆 存储库 并“vagrant up”。一旦事情启动并运行，您可以：
在以下位置击中霸王：
http://192.168.50.4:8080/console.html
在以下位置点击协调员：
在我的下一篇博客中，我将详细介绍使用直接 Finagle API 集成 Tranquility 的客户端。