1.1  Kafka的特性:

- 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。

- 可扩展性：kafka集群支持热扩展

- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

- 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

- 高并发：支持数千个客户端同时读写

适用场景:

1.2   Kafka的使用场景：

- 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

- 消息系统：解耦和生产者和消费者、缓存消息等。

- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

- 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

- 流式处理：比如spark streaming和storm

- 事件源

1.消息分区:

Kafka 的消息组织方式实际上是三级结构：主题 - 分区 - 消息。主题下的每条消息只会保存在某一个分区中，而不会在多个分区中被保存多份。

分区作用: 提供负载均衡的能力,或者说对数据进行分区就是为了实现系统的高伸缩性,不同的分区能够放到不同的节点机器上,而数据的读写操作也是在分区这个粒度上进行的,这样每个节点的机器都能独自的执行各自分区的读写请求处理,也可以增加机器部署节点,增加系统的吞吐量,

1.消息分区broker挂掉怎么处理

controller在启动时会注册zk监听器来监听zookeeper中的/brokers/ids节点下子节点的变化，即集群所有broker列表，而每台broker在启动时会向zk的/brokers/ids下写入一个名为broker.id的临时节点，当该broker挂掉或与zk断开连接时，此临时节点会被移除（这是zk提供的功能），之后controller端的监听器就会自动感知到这个变化并将BrokerChange事件写入到controller上的请求阻塞队列中。

 

消息的顺序性:

1.设置一个分区,这样的话就能保证消息的有序,但是性能就会大大的下降

2.按照消息键保序策略,通过对消息键设置值,消息键相同的都会保存到同一分区中去,kafka默认的分区策略就是如果指定了消息键key,那么就按照消息键保序策略,如果没有的话则按照轮询的策略

 

无消息就是配置

对已提交的消息做有限度的持久化,

已提交的消息:当kafka的若干个broker成功的接收到一条消息并保存到日志文件中去,那么就可以说这个消息不会丢失

消息丢失两种可能:

生产者程序丢失消息,调用send()方法时要调带回调函数的send(msg,callback),一旦消息发送失败,就可以针对性的处理

消费者程序丢失数据:消费者消息消费位移,保证先消费,再位移,可能会导致消息重复消费问题,多线线程消费,其中一个消费失败也回出现位移丢失现象,最后多线程下子手动提交位移,

位移提交分自动提交,和手动提交

自动提交:容易出现reblance,在默认情况下，Consumer 每 5 秒自动提交一次位移。现在，我们假设提交位移之后的 3 秒发生了 Rebalance 操作。在 Rebalance 之后，所有 Consumer 从上一次提交的位移处继续消费，但该位移已经是 3 秒前的位移数据了，故在 Rebalance 发生前 3 秒消费的所有数据都要重新再消费一次。虽然你能够通过减少 auto.commit.interval.ms 的值来提高提交频率，但这么做只能缩小重复消费的时间窗口，不可能完全消除它。这是自动提交机制的一个缺陷。

手动提交:分为异步提交和同步提交

同步提交会堵塞资源,直到远端的broker返回结果才会结束

异步提交:提供了回调函数,可以实现提交之后的逻辑,commitAsync 是否能够替代 commitSync 呢？答案是不能。commitAsync 的问题在于，出现问题时它不会自动重试。因为它是异步操作，倘若提交失败后自动重试，那么它重试时提交的位移值可能早已经“过期”或不是最新值了。因此，异步提交的重试其实没有意义，所以 commitAsync 是不会重试的。

显然，如果是手动提交，我们需要将 commitSync 和 commitAsync 组合使用才能到达最理想的效果，原因有两个：我们可以利用 commitSync 的自动重试来规避那些瞬时错误，比如网络的瞬时抖动，Broker 端 GC 等。因为这些问题都是短暂的，自动重试通常都会成功，因此，我们不想自己重试，而是希望 Kafka Consumer 帮我们做这件事。我们不希望程序总处于阻塞状态，影响 TPS。