kafka原理以及使用（1）

1 Kafka的特性
高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
可扩展性：kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写

2Kafka设计思想和名词解释

名词	解释
Producer	消息和数据生成者，向Kafka的一个topic发布消息的 过程叫做producers
Consumer	消息和数据的消费者，订阅topic并处理其发布的消费过程叫做consumers
ConsumerGroup	消费者组，可以并行消费Topic中的partition的消息。 各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果一个消息 可以被多个consumer消费的话，那么这些consumer必须在不同的组。
Broker	缓存代理，Kafka的服务实例就是一个broker
Topic	Kafka处理资源的消息源(feeds of messages)的不同分类
Partition	Topic物理上的分组，一个topic可以分为多个partion,每个partion是一个有序的队列。 partion中每条消息都会被分配一个 有序的Id(offset)
Message	消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息
offset	partition中下一个要被消费的消息位置

消息状态：在Kafka中，消息的状态被保存在consumer中，broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置），这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次。
消息持久化：Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。
消息有效期：Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。
批量发送：Kafka支持以消息集合为单位进行批量发送，以提高push效率。
push-and-pull : Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向broker push消息，consumer只管从broker pull消息，两者对消息的生产和消费是异步的。
Kafka集群中broker之间的关系：不是主从关系，各个broker在集群中地位一样，我们可以随意的增加或删除任何一个broker节点。
负载均衡方面： Kafka提供了一个 metadata API来管理broker之间的负载（对Kafka0.8.x而言，对于0.7.x主要靠zookeeper来实现负载均衡）。
同步异步：Producer采用异步push方式，极大提高Kafka系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。
分区机制partition：Kafka的broker端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。分区的意义很重大，后面的内容会逐渐体现。
离线数据装载：Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。
插件支持：现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。

kafka 应用场景
日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
流式处理：比如spark streaming和storm
事件源

kafka有一个核心的概念叫做“Topic”，消息处理的集合。不同的topic做不同的消息处理。
下面有Partition，分区，每个topic下有多个partition，不同的partition可以放到不同的服务器上。
多台服务器上有partition时，其中有一个Leader，可对外提供读写操作。剩下的都是Follower,需要实时同步。
当Leader宕机后，会重新选举一个Follower成为Leader。


Kafka 写入数据丢失问题
a业务往Leader写入了数据,Leader还没有同步到Follower ，此时
Follower成为了Leader ，但是因为数据没同步过去，所以导致这条数据丢失了。

Kafka 的 ISR 机制
Kafka的核心机制，ISR 机制。
自动给每个Partition维护一个ISR 列表,里边的leader和Follower始终是同步的。
如果follewer由于自身关系没成功同步leader数据,这个Follower 就会被认为是“out-of-sync”,被从 ISR 列表里踢出去

Kafka 写入的数据如何保证不丢失
ISR 列表中始终有一个leader和Follower。
每次写入数据的时候，只有leader和Follower同时写入成功，才算成功。