《3.10.1 kafka入门和使用场景》

• 简介：
  
• 8 50 主流MQ对比：
  吞吐量 Kafka>RabbitMQ>ActiveMQ
  准确性 RabbitMQ>ActiveMQ>Kafka
  一般来说，数据场景用Kafka
  

leader partition可读可写，follower partition只可读。
数据被写到leader后，会同步到follower。leader如果挂了，follower们会有选举，原leader重新上线后会成为follower。
59 40 可以指定往Kafka写数据成功的定义：比如往leader和follower都写成功

• 76分 四个Kafka核心API：
  

《3.10.2 Kafka Connect数据传输作业工具》

• 3 40 record中的timestamp意义1：可用于决定它是否过期，以被删除；意义2：让消费者决定只消费指定时间的消息

• 11 40 producer.send方法异步。原理：只先把消息发送至本地buffer。后台IO线程会将buffer中的数据批量发送（linger.ms默认为0，即实时发送而非批量发送，实时性好，但不利于提高吞吐量）
  
  准确来说，ack=All是表示leader和所有的ISR副本同步完成。ISR：跟上了leader节奏的副本。可见于《3.10.3 Kafka Streams架构》76:30

• 27 50 Kafka的使用场景1：
  
  31 20 一个partition只能被一个Consumer Group中的一个Consumer消费，决定了Kafka的消息顺序性比ActiveMQ和RabbitMQ好？

• 34 16+ 使用场景2：
  
  Kafka的数据存储与被消费无关

• 49 19 使用场景3：ELK中使用，为Logstash削峰

• 55 1+ 其它使用场景： 跟踪网站活动；流处理

《3.10.3 Kafka Streams架构》

• 8 10 对于一个Consumer Group而言，一个partition只能被中的一个Consumer消费，但是一个Consumer可以消费多个partition。
  每个Consumer Group消费的是全量数据（topic的全量数据？我尚未在实践中证实）

• 23 10+ commit
  48 30 consumer.poll方法的offset记录在消费者的内存中，commit时才会落地到Kafka中。
  要求强一致性时，建议在消费者本地保存offset记录
  

  扫描二维码关注公众号，回复： 12983355 查看本文章

《3.10.4 Kafka优雅应用》

• Kafka为什么高效：
• • 顺序写磁盘。如下图，顺序写磁盘高于随机写内存：
    
• • Kafka也用内存，但使用的是OS的page cache内存。
    详细可见《聊聊page cache与Kafka之间的事儿》，这里摘几句：

page cache用于缓存文件的页数据。

page cache的目的是加速数据I/O：写数据时首先写到缓存，将写入的页标记为dirty，然后向外部存储flush，也就是缓存写机制中的write-back（另一种是write-through，Linux未采用）

page cache中的数据会随着内核中…写回到磁盘，就算进程崩溃，也不用担心数据丢失。另外，如果consumer要消费的消息不在page cache里，才会去磁盘读取，并且会顺便预读出一些相邻的块放入page cache，以方便下一次读取。

41 40 零拷贝的示意图如下。Kafka有用到Netty?

• 总体概括Kafka高效的原因：
  

• 26 20 消费端。推的优点：实时；缺点：可能超过消费者的接收处理速度。Kafka使用的是拉（poll）

• 51 50 添加partition的命令

• 56 30 在各节点上重新分配partition的脚本，比如节点数变化时需要

• 65 35+ Kafka如何做到不丢数据，甚至exactly once:
  Consumer: 如上一节所记，在Consumer本地保存offset记录
  Broker: 高可用。注意replic数和IRS数的设置
  Producer: acks=all，另外注意设置retries，即重试次数。但是可能会导致消息重复，为了解决重复消息的问题，设置唯一id?

• 75 35+ kafka在生产环境遭遇业务区网卡流量激增的应对方案：多网卡，让消费端从数据区连过来，从而走数据区的交换机