asahi/rikako-note
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

继续关于Kafka文档的阅读

Browse Source
This commit is contained in:
Rikako Wu
2023-02-21 09:54:35 +08:00
parent 9f8ee7e160
commit 949bad547e
1 changed files with 7 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
mq/kafka/kafka.md
View File

@@ -292,6 +292,12 @@ Kafka支持GZIP，LZ4，ZStandard压缩协议。
#### 异步发送 #### 异步发送
批量处理是提高性能的重要因素之一，为了支持批量处理，Kafka生产者会在内存中累计数据并在单个请求中发送更大的批数据。批处理可以被配置为累计不超过固定数量的消息或不超过特定界限的延迟（例如64K，10ms）。 批量处理是提高性能的重要因素之一，为了支持批量处理，Kafka生产者会在内存中累计数据并在单个请求中发送更大的批数据。批处理可以被配置为累计不超过固定数量的消息或不超过特定界限的延迟（例如64K，10ms）。
### 消费者 ### 消费者
Kafka消费者会向其消费分区的leader broker发送fetch请求。消费者在每次请求中指定log offset并从该位置接收一块log。consumer对于位置具有绝对的控制权，故而在需要时可以执行rewind操作对数据进行重新消费。
#### push vs pull
在Kafka的实现中，和大多数消息系统一样，data从生产者push到broker，消费者从broker中pull data。
#### consumer position
其他消息系统消费者通常使用ack来告知broker该消息已经被正确处理，但是这样会存在如下问题：如果被consumer拉取的消息被处理，但是在发送ack之前消费者失败，那么该消息会被重复消费。
相比于通过ack来保证消息被消费者正确处理，kafka通过其他方式来对其进行处理。kafka topic由一系列分区组成，在一个时间点，每个分区都只会由一个consumer group中的一个消费者实例消费。每个消费者实例只需要维护一个integer，作为ack确认的等价物，维护position的开销相当小。
#### 静态成员 #### 静态成员
静态成员用于提升基于group rebalance协议应用的性能。rebalance协议依赖于组协调器，组协调器用于为组成员分配实体id。组协调器产生的实体id是短暂的，并且当成员重启并重新加入到组之后，实体id会发生变化。对于基于consumer的app，上述“动态成员”可能会造成在应用周期性重新启动时大量任务会被新分配给其他消费者实例。 静态成员用于提升基于group rebalance协议应用的性能。rebalance协议依赖于组协调器，组协调器用于为组成员分配实体id。组协调器产生的实体id是短暂的，并且当成员重启并重新加入到组之后，实体id会发生变化。对于基于consumer的app，上述“动态成员”可能会造成在应用周期性重新启动时大量任务会被新分配给其他消费者实例。
由于上述缺点，Kafka group管理协议允许组成员提供持久的实体id，基于这些id，组成员身份保持不变，故而rebalance不会被触发。 由于上述缺点，Kafka group管理协议允许组成员提供持久的实体id，基于这些id，组成员身份保持不变，故而rebalance不会被触发。
@@ -309,5 +315,4 @@ Kafka的语义是直截了当的，当消息被发布时，有一个消息被提
在0.11.0.0之前，如果一个生产者没有接收到消息已经成功被提交的相应，那么生产者会重新发送该消息。这种实现提供了at-least-once的语义，如果前一次消息已经被写入到log中，那么重新发送的重复消息仍会被重复写入到log中。 在0.11.0.0之前，如果一个生产者没有接收到消息已经成功被提交的相应，那么生产者会重新发送该消息。这种实现提供了at-least-once的语义，如果前一次消息已经被写入到log中，那么重新发送的重复消息仍会被重复写入到log中。
自从0.11.0.0开始，kafka生产者还支持幂等传输选项，幂等传输会保证消息的重复发送并不会导致log中存在重复条目。为了实现幂等传输，broker会分配给每个生产者一个id，并且通过和每条消息一起发送的序列号来判断去除重复消息。**同时，从0.11.0.0开始，生产者支持以类似事务的方式向多个topic分区发送多条消息：要么所有的消息被成功写入，要么所有的消息都未被写入。** 自从0.11.0.0开始，kafka生产者还支持幂等传输选项，幂等传输会保证消息的重复发送并不会导致log中存在重复条目。为了实现幂等传输，broker会分配给每个生产者一个id，并且通过和每条消息一起发送的序列号来判断去除重复消息。**同时，从0.11.0.0开始，生产者支持以类似事务的方式向多个topic分区发送多条消息：要么所有的消息被成功写入，要么所有的消息都未被写入。**
但是，并非是所有的用例都需要如此严格的保证。对于延迟敏感的场景，生产者可以指定其期望持久性级别。如果生产者指定其需要等待消息被提交，那么可能会需要10ms；但是生产者也可以指定异步发送消息或只需要等待到leader broker收到该信息（followers不用收到）。 但是，并非是所有的用例都需要如此严格的保证。对于延迟敏感的场景，生产者可以指定其期望持久性级别。如果生产者指定其需要等待消息被提交，那么可能会需要10ms；但是生产者也可以指定异步发送消息或只需要等待到leader broker收到该信息（followers不用收到）。