文章目录

• 一、应用场景
• 二、与ZK的管理
• 三、架构分析
• • 1 Broker
  • 2 消息
  • 3 生产者
  • 4 消费者
  • 5 Topic
  • 6 Partition 与 Cluster
  • 7 Partition 副本 Replica 机制
  • 8 Segment
  • 9 Consumer Group
  • 10 Consumer Offset
• 四、数据同步问题
• 五、进接特性
• • 1、消息幕等性
  • 2、生产者事务

Kafka由Linkedln开发，捐给了apache

一、应用场景

1、消息传递
	实现异步削峰
2、大数据领域
	网站活动跟踪，日志聚合，应用指标监控
3、数据集成+流计算
	导入Hadoop、HBase中，进而数据分析处理

二、与ZK的管理

利用ZK的有序节点、临时节点和监听机制，
ZK帮kafka做了这些事情: 配置中心，负载均衡、命名服务、分布式通知、集群管理和选举、分布式锁

三、架构分析

1 Broker

kafka的服务叫做Broker

2 消息

客户端之间传输的数据叫做消息

3 生产者

发送消息的一方叫做生产者，接收消息的一方叫做消费者。
为了提升消息发送速率，生产者不是逐条发送消息给Broker,而是批量发送的。 多少条发送一次由一个参数决定。

4 消费者

—般来说消费者获取消息有两种模式，一种是pull模式，一种是push模式。
Pull模式就是消费放在Broker,消费者自己决定什么时候去获取。Push模式是消息放在Consumer,只要有消息
到达Broker,都直接推给消费者。Kafka只有pull模式。

为什么消费者用pull
	在push模式下，如果消息产生速度远远大于消费者消费消息的速率，那消费者就会不堪重负（你已经吃不
下了，但是还要不断地往你嘴里塞），直到挂掉。而且消费者可以自己控制一次到底获取多少条消息:
max.poll. records默认500。在poll方法里面可以指定。

5 Topic

在kafka里面，这个队列叫做Topic,是一个逻辑的概念，可以理解为一组消息的集
生产者和Topic以及Topic和消费者的关系都是多对多。一个生产者可以发送消息 到多个Topic, 
一个消费者也可以从多个Topic获取消息

6 Partition 与 Cluster

	kafka引入了一个分区(Partition)的概念。一个Topic可以划分成多个分区。 分区在创建topic的时
候指定，每个topic至少有一个分区。
	如果没有指定分区数，默认的分区数是一个
	partitions是分区数,replication-factor是主题的副本数
	Partition里面的消息被读取之后不会被删除 所以 同一批消息在一个Partition里面顺序、追加写入的。

7 Partition 副本 Replica 机制

	每个partition可以有若干个副本(Replica),副本必须在不同的Broker面。— 般我彳门说的副本包括
其中的主节点。
	由 replication-factor 指定一个 Topic 的副本数

8 Segment

	kafka的数据是放在后缀.log的文件里面的。如果一个partition只有一个log文件, 消息不断地追加，
这个log文件也会变得越来越大，这个时候要检索数据效率就很低了。所以干脆把partition再做一个
切分，切分出来的单位就叫做段（segment)。实际 上kafka的存储文件是划分成段来存储的。

9 Consumer Group

	在代码中通过group id来配置。消费同一个topic的消费者不一定是同一个组，
只有group id相同的消费者才是同一个消费组

10 Consumer Offset

消息是有序的，我们可以对消息进行编号，用来标识一条唯一的消息。这个编号我们就把它叫做offset,偏移量

四、数据同步问题

使用canal，分析binlog日志，获取消息

五、进接特性

1、消息幕等性

1、PID(Product ID)
	幕等性的生产者每个客户端都有一个唯一标识
2、sequence number
	幕等性的生产者发送的每条消息都会带相应的sequence number, Server端就是根据这个值来判
断数据是否重复。如果说发现sequence number比服务端已经记录的值要小，那肯定是出现消息重复了
	2.1、只能保证单分区上的幕等性，即一个幕等性Producer能够保证某个主题的一个 分区上不出现重复
	消息。
	2.2、只能实现单会话上的幕等性，这里的会话指的是Producer进程的一次运行。当 重启了 Producer
	进程	之后，幕等性不保证

2、生产者事务

A:生产者通过 initTransactions API 向 Coordinator 注册事务 IDO
B: Coordinator记录事务日志。
C:生产者把消息写入目标分区。
D:分区和Coordinator的交互。当事务完成以后，消息的状态应该是已提交，这样消费者才可以消费到。