1 进程类型
Druid内部有几种进程模式，分别是Coordinator进程、Overlord进程、Broker进程、Router、Historical进程、MiddleManager进程，具体已在 架构设计 整体设计中介绍，有兴趣的同学可前往了解。
本篇教程将着重介绍一下Druid中的服务类型。
2 服务类型
Druid进程支持自定义部署、混合部署。但我们建议以最便捷的方式部署为以下三种类型，分别是：
本节将来介绍Druid进程和我们建议的Master/Query/Data server服务类型，如上面的架构图所示。
1）Master服务
负责数据摄取操作的管理，以及对数据可用性进行协调。
Master服务中主要分为两个子进程：Coordinator和Overlord。
Coordinator负责发送数据段给指定服务器，同时负责监控Historical进程。
Overlord负责控制Druid的数据接收，和将接受到的任务分发至MiddleManager中。此外，Overlord还负责协调数据段的发布。
2）Query服务
Query为用户以及终端提供交互服务，主要体现在Query会将查询请求发送至服务器或者其他服务进程中。
Query服务的功能上主要分为两个子进程：Broker和Router。
Broker从外部客户端接收到查询请求，然后将这些查询请求转发至服务器。当Broker接收到返回的查询结果时，它将会对这些返回结果进行合并然后发送至客户端。
通常用户会选择使用Broker来进行查询，而不是直接调用Data服务里的Historical或MiddleManager进程。
Router属于可选进程，该进程相当于是为Druid Broker、Overlord和Coordinator提供一个统一的API网关；
Router还运行着Druid控制台：一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。
3）Data服务
Data服务用于摄取数据并对可查询的数据进行存储。
在Data服务中，根据功能被分为两个进程：Historical和MiddleManager。
Historical进程是处理存储和查询Historical的数据（包括系统中已提交的任何流数据）的工作程序；
Historical进程会从深层存储中下载数据段，并对相关的数据段查询请求进行响应；
Historical进程不接受写操作。
MiddleManager进程主要用于处理新数据摄取到集群中的操作过程，并负责读取外部的数据源、以及发布新的Druid数据段。
Peon进程是由MiddleManagers生成的任务执行引擎；
每个Peon运行单独的JVM，并负责执行一个任务；
Peon总是和孕育它的MiddleManager在同一个主机上运行。
4）Indexer进程（可选）
Indexer进程是MiddleManager和Peon的替代方法；
Indexer在单个JVM进程中作为单线程来执行任务。
与MiddleManager + Peon系统相比，Indexer进程的设计更易于配置、部署，并且能够更好地实现跨任务的资源共享；
通常您可以选择部署MiddleManagers还是indexer，但两者不能同时部署。
3 服务混合部署的利弊
Druid进程可以基于上面所介绍的Master/Data/Query服务类型进行混合部署，这种部署方式通常能够让大多数的集群更好地利用硬件资源。
但是，对于规模十分庞大的集群而言可以选择分割Druid进程，让集群能在单独的服务器上运行，避免资源争夺。
本节将介绍与进程混合部署相关的指南和配置参数。
1）Coordinator和Overlord
Coordinator进程的工作负载往往随着集群中数据段的数量增加而增加。
Overlord的工作量也会根据集群中的分段数而增加，但程度要比Coordinator小。
在大量的段的集群中，我们可以将Coordinator进程和Overlord进程分开，便于为Coordinator进程的分段平衡工作负载提供更多资源。
统一进程
设置druid.Coordinator.asOverlord.enabled属性，能够使得Coordinator进程和Overlord进程作为单个组合进程运行。
2）Historical和MiddleManager
对于更高级别的数据摄取或查询负载，将Historical进程和MiddleManager进程部署在不同主机上以避免CPU和内存争用。
Historical还受益于为内存映射段提供可用内存，这也是分别部署Historical和MiddleManager进程的另一个原因。
