gebilaozeng的博客

3.3.1 消费方式consumer采用pull（拉）模式从broker中读取数据。  cpush（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。  pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时

Flume拓扑结构一、简单串联 该结构为Flume与Flume之间通过sink和source进行简单得串联，但该结构模式不建议桥接过多的Flume数量， Flume数量过多不仅会影响传输速率，而且一旦传输过程中某个节点flume宕机或者故障，会影响整个传输系统。二、复制和多路复用 这里得复制和多路复用通过设置ChannelSelector可以实现，分别是Replicating（复制）和Multiplexing（多路复用）。三、负载均衡和故障转移 Flume支持使用将多个sink，在逻辑上分

Flume事务 Flume是一个基于流式架构一个日志收集传输系统，内部流式处理框架如下图：Put事务： (1) doPut：负责将Source拿到得数据上传到临时缓冲区putList中 (2）doCommit：该过程会检查Channel队列得大小是否足够存储putList中得数据，如果空间足够大，则执行doCommit将数据传到Channael; (3)：doRollback：在步骤(2)当中，如果Channel队列得内存空间不足，则回滚数据;Take事务： (1) doTake：负责将数据

Flume概述一、 Flume定义 Flume是Cloudera提供的一个高可用的，高可靠（failover）的，分布式的海量日志采集、聚合和传输的系统。Flume基于流式架构，灵活简单。 Flume一般运用于读取服务器磁盘里的数据并写入到HDFS当中；二、 Flume基本架构Flume组成架构如下图所示：Agent Agent是一个JVM进程，它以事件的形式将数据从源头送至目的。 Agent主要有3个部分组成，Source、Channel、Sink。 Source Source是负

producer到broker的消息发送流程  Kafka的Producer发送消息采用的是异步发送的方式。在消息发送的过程中，涉及到了两个线程——main线程和Sender线程，以及一个线程共享变量——RecordAccumulator。main线程将消息发送给RecordAccumulator，Sender线程不断从RecordAccumulator中拉取消息发送到Kafka broker。相关参数：batch.size：只有数据积累到batch.size之后，sender才会发送数据。lin

关于Kakfa事物的简要分析： Kafka从0.11版本开始引入了事务支持。事务可以保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。Producer事务 为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。 为了管理Transaction，Kafka引

Kafka实现高效数据读写方式：一、顺序写磁盘 Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。根据官网数据表明，同样的磁盘，顺序写能到到600M/s，而随机写只有100k/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。二、应用Pagecache Kafka数据持久化是直接持久化到Pagecache中，这样会有几个优势：  （1）I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能。  （2

关于Controller: 根据Kafka的数据可靠特性可以知道，Kafka的数据可靠性以及leader节点的选举需要靠Zookeeper维护。 Kafka集群中有一个broker节点会被选举为Controller，负责管理集群broker的上下线，以及所有topic的分区副本分配和leader选举等工作。而Controller的管理工作都是依赖于Zookeeper。Zookeeper维护下的Kafka的Leader节点选举：图一： 根据图一可以知道，Zookeeper维护了Kafka集群的每个

数据可靠性保证: 为保证producer发送的数据能够可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到，也就是应答），如果producer收到ack，就会进行下一轮的数据发送，否则重新发送数据。 如下图：ack发送机制方案: 首先需要确保收到消息后节点中的follower与leader节点的数据同步完成，然后leader节点再发送ack应答给producer，这样才可以保证突

1）分区的原因  （1）为了方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了； （2）可以提高并发，因为可以以Partition为单位读写（Partition多副本）2）分区策略  首先生产者生产数据后需要发送数据，而发送的数据则会封装成ProducerRecord对象，ProducerRecord对象在new的时候可以加入如下参数: （1）指明 partition 的情况下，直接将

   Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。   topic是逻辑上的概念（可以自己定义），而partition是物理上的概念（可以将一个topic的内容分配到不同节点上的物理磁盘中），每个partition对应于一者log文件，该log文件中存储的就是producer生产的数...

**    Kafka是一个分布式的的基于发送/订阅模式的消息队列，可以应用于大数据的实时处理领域**   我们都知道消息队列一般都有两种模式，为点对点模式（一对一）和发布/订阅模式（一对多）。   对于先对点模式，它是消息消费者在消费队列里面的消息之后，被消费的消息就会被删除，也就是一个消息只能被一个消...