Kafka - 版本历史

Eijux：/* 数据消费过程（Consume） */

2022-10-31T21:14:01Z

数据消费过程（Consume）

←上一版本		2022年11月1日 (二) 05:14的版本
第151行：		第151行：

	'''消费方式：'''		'''消费方式：'''

	在 kafka 中，采用了 '''pull''' 方式，即 consumer 在和 broker 建立连接之后，主动去 pull（或者说 fetch）消息，首先 consumer 端可以根据自己的消费能力适时的去 fetch 消息并处理，且可以控制消息消费的进度（offset）。		在 kafka 中，采用了 '''pull''' 方式，即 consumer 在和 broker 建立连接之后，主动去 pull（或者说 fetch）消息，首先 consumer 端可以根据自己的消费能力适时的去 fetch 消息并处理，且可以控制消息消费的进度（offset）。
	partition 中的消息只有一个 consumer ~~在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见~~ kafka broker 端是相当轻量级的。
			partition 中的消息只有一个 consumer 在消费，且'''不存在消息状态的控制，也没有复杂的消息确认机制'''，可见 kafka broker 端是相当轻量级的。

	'''消费进度：'''		'''消费进度：'''

	当消息被 consumer 接收之后，需要保存 '''Offset''' 记录消费到哪，以前保存在 ZK 中。		当消息被 consumer 接收之后，需要保存 '''Offset''' 记录消费到哪，以前保存在 ZK 中。

	由于 ZK 的写性能不好，以前的解决方法都是 Consumer 每隔一分钟上报一次，在 0.10 版本后，Kafka 把这个 Offset 的保存，从 ZK 中剥离，保存在一个名叫 '''consumeroffsets topic''' 的 Topic 中，由此可见，consumer 客户端也很轻量级。		由于 ZK 的写性能不好，以前的解决方法都是 Consumer 每隔一分钟上报一次，在 0.10 版本后，Kafka 把这个 Offset 的保存，从 ZK 中剥离，保存在一个名叫 '''consumeroffsets topic''' 的 Topic 中，由此可见，consumer 客户端也很轻量级。

Eijux：/* Kafka 集群架构 */

2021-05-17T11:51:29Z

Kafka 集群架构

←上一版本		2021年5月17日 (一) 19:51的版本
第203行：		第203行：


	'''~~问题：所以~~ zookeeper 不光协调 Broker，还要协调 partition 的 replicas？？？'''		'''问题：'''
			: '''所以 zookeeper 不光协调 Broker，还要协调 partition 的 replicas？？？'''

Eijux：/* 总结 */

2021-05-17T11:51:12Z

总结

←上一版本		2021年5月17日 (一) 19:51的版本
第182行：		第182行：


	'''~~问题：一个~~ client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。'''		'''问题：'''
			: '''一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。'''
	: '''或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？'''		: '''或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？'''

Eijux：/* 总结 */

2021-05-17T11:50:39Z

总结

←上一版本		2021年5月17日 (一) 19:50的版本
第182行：		第182行：


	问题：一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。		'''问题：一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。'''
	: 或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？		: '''或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？'''

	== Kafka 集群架构 ==		== Kafka 集群架构 ==

Eijux：/* Kafka 集群架构 */

2021-05-17T11:50:20Z

Kafka 集群架构

←上一版本		2021年5月17日 (一) 19:50的版本
第186行：		第186行：

	== Kafka 集群架构 ==		== Kafka 集群架构 ==
			Kafka的集群图：
			: [[File:Kafka：集群架构.png\|600px]]

			其中：
			# '''Broker'''（代理）：
			#: Kafka 集群通常由多个 Broker 组成以保持负载平衡。Kafka代理是无状态的，所以他们使用ZooKeeper来维护它们的集群状态。一个Kafka代理实例可以每秒处理数十万次读取和写入，每个Broker可以处理 TB 的消息，而没有性能影响。
			#* Broker Leader 选举可以由ZooKeeper完成。
			# '''ZooKeeper'''：
			#: ZooKeeper 用于'''管理和协调 Broker'''。 ZooKeeper服务主要用于通知生产者和消费者 Kafka 系统中存在任何新 Broker 或 Kafka 系统中 Broker 失效。根据 Zookeeper 接收到关于代理的存在或失败的通知，然后生产者和消费者采取决定并开始与某些其他代理协调他们的任务。
			# '''Producers'''（生产者）：
			#: 生产者将数据推送给经纪人当新 Broker 启动时，所有生产者搜索它并自动向该新 Broker 发送消息。Kafka生产者不等待来自 Broker 的确认，并且发送消息的速度与代理可以处理的一样快。
			# '''Consumers'''（消费者）：
			#: 因为 Kafka 代理是无状态的，这意味着消费者必须通过使用分区偏移（'''offset'''）来维护已经消耗了多少消息。如果消费者确认特定的消息偏移，则意味着消费者已经消费了所有先前的消息。消费者向代理发出异步拉取请求，以具有准备好消耗的字节缓冲区。消费者可以简单地通过提供偏移值来快退或跳到分区中的任何点。
			#* 消费者偏移值由 ZooKeeper 通知。


			'''问题：所以 zookeeper 不光协调 Broker，还要协调 partition 的 replicas？？？'''

Eijux：/* 总结 */

2021-05-17T11:40:13Z

总结

←上一版本		2021年5月17日 (一) 19:40的版本
第184行：		第184行：
	问题：一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。		问题：一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。
	: 或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？		: 或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？

			== Kafka 集群架构 ==

Eijux：/* 总结 */

2021-05-17T11:39:29Z

总结

←上一版本		2021年5月17日 (一) 19:39的版本
第180行：		第180行：
	关于 Kafka 的“发布订阅”：		关于 Kafka 的“发布订阅”：
	: 其是对 consumer group 而言，而不是对 consumer 而言。【因为消息是被多个 consumer group 订阅，而被其中的一个 consumer 消费】		: 其是对 consumer group 而言，而不是对 consumer 而言。【因为消息是被多个 consumer group 订阅，而被其中的一个 consumer 消费】


			问题：一个 client 是不是需要多个 consumer？毕竟一个 consumer 不能收取一整个 topic 的消息。
			: 或者一个 client 对应一个（收取一个topic）或多个（收取多个topic）的 consumer group？？？

Eijux：/* 数据生产过程（Produce） */

2021-05-17T11:36:30Z

数据生产过程（Produce）

←上一版本		2021年5月17日 (一) 19:36的版本
第123行：		第123行：
	* 如果 Partition 没填，那么情况会是这样的：		* 如果 Partition 没填，那么情况会是这样的：
	*# Key 有填：'''按照 Key 进行哈希'''，相同 Key 去一个 Partition。		*# Key 有填：'''按照 Key 进行哈希'''，相同 Key 去一个 Partition。
	*# Key 没填：'''Round-Robin''' 来选 ~~Partition。【？？？】~~		*# Key 没填：'''Round-Robin''' 来选 Partition。【即：循环/轮转/轮替地选择 partiton】

	: [[File:Kafka：数据流程：数据生产过程（Produce）.png\|600px]]		: [[File:Kafka：数据流程：数据生产过程（Produce）.png\|600px]]

Eijux：/* 总结 */

2021-05-17T11:35:48Z

总结

←上一版本		2021年5月17日 (一) 19:35的版本
第167行：		第167行：
	在业务中，常常都是使用 '''At least once''' 的模型。【为啥不用 Exactly Once ？？？】		在业务中，常常都是使用 '''At least once''' 的模型。【为啥不用 Exactly Once ？？？】

	=== 总结 ===		=== '''总结''' ===
	要点：		要点：
	# 消息以 topic 作为分类，而一个 topic 又对应多个 partition，而 partition 又存在多个 replicas（其协调依赖于 Zookeeper）；		# 消息以 topic 作为分类，而一个 topic 又对应多个 partition，而 partition 又存在多个 replicas（其协调依赖于 Zookeeper）；

Eijux：/* 消息传送机制 */

2021-05-17T11:35:32Z

消息传送机制

←上一版本		2021年5月17日 (一) 19:35的版本
第166行：		第166行：

	在业务中，常常都是使用 '''At least once''' 的模型。【为啥不用 Exactly Once ？？？】		在业务中，常常都是使用 '''At least once''' 的模型。【为啥不用 Exactly Once ？？？】

			=== 总结 ===
			要点：
			# 消息以 topic 作为分类，而一个 topic 又对应多个 partition，而 partition 又存在多个 replicas（其协调依赖于 Zookeeper）；
			# 消息被 producer 发送到 broker，可用的参数：topic、partition、key、value。其中：
			## topic、value，是消息的分类和主体，是必须的；
			## partition、key，用以确定消息位于 topic 的哪个 partition，是可选的；
			# 消息只被“每个 consumer group 中的一个 consumer”所消费【就是 consumer group 中的每一个 consumer 对应 topic 的一个 partition】【所以 consumer group 中 consumer 的个数不能多余 topic 的 partition 个数】；
			#* 每个 consumer 使用 pull 方式主动拉去消息；并用 consumeroffsets topic 保存其消费在 partition 中的 offset【因为 partition 实质是一个 append log 文件】。
			#* 若所有 consumer 都在同一个 consumer group，则实质为点对点消息模型；若每一个 consumer 都有一个单独的 consumer group，则实质为广播消息模型；


			关于 Kafka 的“发布订阅”：
			: 其是对 consumer group 而言，而不是对 consumer 而言。【因为消息是被多个 consumer group 订阅，而被其中的一个 consumer 消费】

Kafka - 版本历史

Eijux：​/* 数据消费过程（Consume） */

Eijux：​/* Kafka 集群架构 */

Eijux：​/* 总结 */

Eijux：​/* 总结 */

Eijux：​/* Kafka 集群架构 */

Eijux：​/* 总结 */

Eijux：​/* 总结 */

Eijux：​/* 数据生产过程（Produce） */

Eijux：​/* 总结 */

Eijux：​/* 消息传送机制 */

Eijux：/* 数据消费过程（Consume） */

Eijux：/* Kafka 集群架构 */

Eijux：/* 总结 */

Eijux：/* 总结 */

Eijux：/* Kafka 集群架构 */

Eijux：/* 总结 */

Eijux：/* 总结 */

Eijux：/* 数据生产过程（Produce） */

Eijux：/* 总结 */

Eijux：/* 消息传送机制 */