大数据面试：Zookeeper与Flume

Zookeeper

1.常用命令

ls 、 get 、 create 、 delete 、 deleteall

2.选举机制

半数机制 （过半机制）： 2n + 1， 安装奇数台。

10 台服务器： 3 台。

20 台服务器： 5 台。

100 台服务器： 11 台。

台数多， 好处： 提高可靠性； 坏处： 影响通信延时。

3.Zookeeper 符合法则中哪两个？

3.1CAP理论

CAP理论告诉我们， 一个分布式系统不可能同时满足以下三种

• 一致性 （C:Consistency）
• 可用性 （A:Available）
• 分区容错性 （P:Partition Tolerance）

这三个基本需求， 最多只能同时满足其中的两项， 因为P是必须的， 因此往往选择就在CP或者AP中。

1） 一 致性 （C:Consistency）

在分布式环境中， 一致性是指数据在多个副本之间是否能够保持数据一致的特性 。 在一致性的需求下， 当一个系统在数 据一致的状态下执行更新操作后， 应该保证系统的数据仍然处于一致的状态 。

2） 可用性 （A:Available）

可用性是指系统提供的服务必须一直处于可用的状态， 对于用户的每一个操作请求总是能够在有限的时间内返回结果。

3） 分区容错性 （P:Partition Tolerance）

分布式系统在遇到任何网络分区故障的时候， 仍然需要能够保证对外提供满足一致性和可用性的服务， 除非是整个网络 环境都发生了故障。

3.2ZooKeeper保证的是CP

（1） ZooKeeper不能保证每次服务请求的可用性 。 （注： 在极端环境下， ZooKeeper可能会丢弃一些请求， 消费者程序需要 重新请求才能获得结果） 。 所以说， ZooKeeper不能保证服务可用性。

（2） 进行Leader选举时集群都是不可用。

Zookeeper 脑裂

Zookeeper 采用过半选举机制， 防止了脑裂。

1. Zookeeper 用来干嘛了

（1） 作为 HA 的协调者： 如 HDFS 的 HA 、 YARN 的 HA。

（2） 被组件依赖： 如 Kafka 、 HBase 、 CK。

Flume

1.Flume 组成， Put 事务， Take 事务

1） Taildir Source

（1） 断点续传 、 多目录

（2） taildir 底层原理

（3） Taildir 挂了怎么办？

不会丢数： 断点续传

重复数据： 有可能

（4） 存在的问题及解决方案

①问题：

新文件判断条件 = iNode 值 + 绝对路径 （包含文件名）

日志框架凌晨修改了文件名称= 》导致会再次重读一次昨天产生的数据 ②解决：

方案一：建议生成的文件名称为带日期的。同时配置日志生成框架为不更名的；

方案二： 修改 TairDirSource 源码， 只按照 iNode 值去确定文件

2） file channel /memory channel/kafka channel

（1） File Channel

数据存储于磁盘， 优势： 可靠性高； 劣势： 传输速度低

默认容量： 100 万个 event

注意： FileChannel 可以通过配置 dataDirs 指向多个路径， 每个路径对应不同的硬盘， 增 大 Flume 吞吐量。

（2） Memory Channel

数据存储于内存， 优势： 传输速度快； 劣势： 可靠性差

默认容量： 100 个 event

（3） Kafka Channel

数据存储于 Kafka， 基于磁盘；

优势： 可靠性高；

传输速度快 Kafka Channel 大于 Memory Channel + Kafka Sink 原因省去了 Sink 阶段

（4） 生产环境如何选择

如果下一级是 Kafka， 优先选择 Kafka Channel。

如果是金融 、 对钱要求准确的公司， 选择 File Channel。

如果就是普通的日志， 通常可以选择 Memory Channel。 每天丢几百万数据 pb 级 亿万富翁， 掉 1 块钱会捡？

3） HDFS Sink

（1） 时间 （半个小时） or 大小 128m 且 设置 Event 个数等于 0， 该值默认 10 具体参数： hdfs.rollInterval=1800， hdfs.rollSize=134217728 且 hdfs.rollCount=0

4） 事务

Source 到 Channel 是 Put 事务

Channel 到 Sink 是 Take 事务

2.Flume 拦截器

1） 拦截器注意事项

（1） 时间戳拦截器： 主要是解决零点漂移问题

2） 自定义拦截器步骤

（1） 实现 Interceptor

（2） 重写四个方法

• initialize 初始化
• public Event intercept(Event event) 处理单个 Event
• public List<Event> intercept(List<Event> events) 处理多个 Event， 在这个方法中调用 Event intercept(Event event)
• close 方法

（3） 静态内部类， 实现 Interceptor.Builder

3） 拦截器可以不用吗？

时间戳拦截器建议使用。如果不用需要采用延迟 15-20 分钟处理数据的方式，比较麻烦。

3.Flume Channel 选择器

Replicating： 默认选择器 。 功能： 将数据发往下一级所有通道。

Multiplexing： 选择性发往指定通道。

4.Flume 监控器

1） 监控到异常现象

采用 Ganglia 监控器， 监控到 Flume 尝试提交的次数远远大于最终成功的次数， 说明 Flume 运行比较差 。 主要是内存不够导致的。

2） 解决办法？

（1） 自身： 默认内存是 20m， 考虑增加 flume 内存， 在 flume-env.sh 配置文件中修改 flume 内存为 4-6g

（2） 找朋友： 增加服务器台数

搞活动 618 = 》增加服务器 = 》用完在退出

日志服务器配置： 8- 16g 内存 、 磁盘 8T

5.Flume 采集数据会丢失吗?

如果是 kafka channel 或者 FileChannel 不会丢失数据，数据存储可以存储在磁盘中。

如果是 MemoryChannel 有可能丢。

6.Flume 如何提高吞吐量

调整 taildir source 的 batchSize 大小可以控制吞吐量， 默认大小 100 个 Event。

吞吐量的瓶颈一般是网络带宽。