kafka学习一

kafka 是一个分布式，分区的，多副本的，多订阅者，基于zookeeper协调的分布式日志系统，也可以做MQ系统，常用于web/nginx日志，访问日志，消息服务等等。

主要用到 ：日志收集系统和消息系统

Kafka主要设计目标如下：（特点）

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
• 同时支持离线数据处理和实时数据处理。
• Scale out:支持在线水平扩展

 

所谓的消息系统就是将数据从一个应用传递到另一个应用，因此，应用本身只用关注数据，无需知道有多少对应的传递对象。

分布式消息传递是基于可靠的消息队列，应用和消息系统之间是异步传递的模式。（消息系统类似于一个中介）

消息系统主要消息传递模式：点对点，发布-订阅。

Kafka是一种发布—订阅模式。

在发布-订阅模式的消息系统中，消息会被持久化到一个topic（标题）中。消费者（应用）可以订阅一个或多个topic，也就是说同一条数据可以被多个消费者消费，即每个数据不会被消费后立刻删除，实现了多对多。

在发布-订阅这种模式下，消息的生产者又被称为发布者，消费者又被称为订阅者。

注意：只有消费者成为订阅者才能收到发布者发送到topic的消息。（只有订阅了topic的消费者擦能收到持久化在topic里的消息数据）

 

Kafka的优势：

1.解耦  

          消息系统是一个中间人，在业务处理流程中，发送方和接收方都一个对应的接口，允许双方独立扩展或者修改两边。

2.冗余（副本）

          在处理数据的过程中，除非数据被持久化，否则就会后失败的可能。只有当消息队列把数据持久化直到这些数据被完全处理后再删除，即kafka得消息队列按照消息队列采取的消息处理范式：插入-获取-删除。把一个消息从topic中删除之前，就已经明确这个消息处理完毕，从而保证数据处理不会失败。

3.扩展性

          因为消息队列的解耦性，所以增大消息的入队和处理频率是很容易的，只需要额外增加处理过程就可以了。不需要改代码也不要调节参数。

4. 灵活性（抗压）

          使用消息队列不会因为访问量剧增等突发性流量增加导致完全崩溃。

5.可恢复性

         消息队列降低了进程间的耦合度，所以当一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统回复后被处理。

6.顺序保证

        数据的处理顺序是一个重点，大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证了一个隔离区域（Partition 分块）内的消息的有序性。

7.缓存

         消息队列通过一个缓冲层来帮助任务最高效率的执行----写入队列的处理会尽可能地快速。该缓冲有助于控制和优化数据流经过系统的速度。

8.异步通信

        很多时候不能及时处理消息，所以消息队列提供了异步处理的机制，允许用户把一个消息放入队列，不进行立即处理，因此可以在需要的时候去处理他们，可以现在topic中放入。

 

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

 

Kafka 集群包含一个或多个服务器，服务器节点称为broker。

broker

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

类似于数据库的表名

Partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

Producer

生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

 

Consumer

消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

Leader

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

Follower

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。