继续关于Kafka文档的阅读

mq/kafka/kafka.md

@@ -316,3 +316,10 @@ Kafka的语义是直截了当的，当消息被发布时，有一个消息被提
 在0.11.0.0之前，如果一个生产者没有接收到消息已经成功被提交的相应，那么生产者会重新发送该消息。这种实现提供了at-least-once的语义，如果前一次消息已经被写入到log中，那么重新发送的重复消息仍会被重复写入到log中。  
 自从0.11.0.0开始，kafka生产者还支持幂等传输选项，幂等传输会保证消息的重复发送并不会导致log中存在重复条目。为了实现幂等传输，broker会分配给每个生产者一个id，并且通过和每条消息一起发送的序列号来判断去除重复消息。**同时，从0.11.0.0开始，生产者支持以类似事务的方式向多个topic分区发送多条消息：要么所有的消息被成功写入，要么所有的消息都未被写入。**  
 但是，并非是所有的用例都需要如此严格的保证。对于延迟敏感的场景，生产者可以指定其期望持久性级别。如果生产者指定其需要等待消息被提交，那么可能会需要10ms；但是生产者也可以指定异步发送消息或只需要等待到leader broker收到该信息（followers不用收到）。   
+在消费者的视角看来，所有的复制分区中，log和offset都完全相同，消费者控制log的位置。如果消费者永远不会宕机，那么可以消费者可以将position存储在内存中；但是如果消费者失败，若想让该topic分区被一个新的消费者实例接管，新的消费者实例需要选定一个position开始处理接管分区。  
+在消费者处理消息并更新position时，有如下选择：
+- `at-most-once`：读取消息，然后将position保存，最后处理消息。这样，如果消费者在保存完position之后崩溃，但此时消息尚未处理完成，那么其他消费者实例接管分区时会从被保存的position开始，即使之前的消息没有被正确处理。
+- `at-least-once`：读取消息，处理消息，然后将position保存。这样，如果消费者在处理完消息但是尚未保存position时崩溃，那么接管该分区的消费者实例可能重复消费先前的数据。这就是`at-least-once`语义。在很多场景下，更新操作是幂等的，故而消息
+- `exactly-once`：当写入到外部系统时，限制是需要协调消费者位置和实际存储内容。通常情况下，实现该功能需要在消费者position的存储系统和消费者输出的存储系统之间引入两阶段提交。但是，可以通过将position和consumer output存储在一个位置来简化该过程。因为任何想要写入的系统可能并不支持两阶段提交。
+> Kafka在Kafka Streams中支持`exactly-once`传输，并且在处理topics之间数据时通过使用transactional producer/consumer来提供`exactly-once`功能。  
+> 其他情况下，kafka默认保证at-least-once传输，但是也允许用户实现at-most-once传输，通过关闭生产者的重试功能并且在处理数据之前提交position变动。