Flume架构设计

我们的架构设计的思路跟美团大同小异，也是分为agent层，collector层和store层。

具体可参考美团架构1，美团架构2，下面只是一些补充：

---

下面是我们自己的架构图：

总体架构

---

数据流图

下面的图描述一条日志消息从客户端产生，经过了怎样的过程最终被消费的。

---

架构说明

美团的文档中已对这个架构的优越性进行了说明，比如可用性，可靠性和可扩展性，这里就不赘述了。

美团自己在Flume的基础做了一些改进和优化，总结如下：

• 美团的各个Flume节点统一使用了dual channel，美团并没有开源。但官方提供了实现类似功能的spillable-memory-channel，但这只是实验版本，并不推荐在生产环境中使用。
• 美团使用的HDFS Sink做了一些优化，比如设置了一个开关，如果HDFS集群维护时关掉；b/m/s优化减少HDFS的压力；自动创建压缩索引等。我们使用的官方HDFS sink则没有这些功能。

在我们实际使用的过程中酌情考虑这些优化。

---

其他说明

• 在API中还增加了一个嵌入式的模式，就是说把agent层的Flume进程嵌入到了应用程序进程，这样是为了方便测试，这样在测试阶段就不需要在本地再部署一个Flume进程了。
• 关于对Flume整套系统的监控和报警（接入Zabbix）和性能测试以及各种异常测试在另外的文章叙述。
• 客户端简单封装下即可。此处暂时不介绍了~

后续会有部署指南和API封装等方面的相关介绍。