生产者是与leader打交道，leader发送数据后，需要等所有的follow写完才可以，这时有一个follow写的慢，迟迟没有写完，需要一等下去
选举机制为时间机制和条数机制，哪个通信时间快，哪个条数多当选leader（高版本删除了条数机制）
无论数据发送多少次，只保留一次（只能解决单次的会话连接，生产者挂了重启就不行了）
3、ack机制决定数据丢不丢0：不用返回
1：leader收到就返回成功
-1:大于等于2不会丢数据
（1）第一个拦截器会在消息发送前将时间戳加入数据消息value的最前部
（2）第二个interceptor会在消息发送后更新成功发送消息数或失败发送消息数。
在企业中必须要清楚流式数据采集框架flume和kafka的定位是什么：
flume：
适合多个生产者；
适合下游数据消费者不多的情况；
适合数据安全性要求不高的操作；
适合与Hadoop生态圈对接的操作。
kafka：
适合数据下游消费众多的情况；
适合数据安全性要求较高的操作，支持replication。
因此我们常用的一种模型是：
线上数据 --> flume --> kafka --> flume(根据情景增删该流程) --> HDFS
kafka：解决多个业务线
flume：扩展的话需要加多个channel，
