阅读kafka文档

mq/kafka/kafka.md

@@ -323,3 +323,36 @@ Kafka的语义是直截了当的，当消息被发布时，有一个消息被提
 - `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变动。  
+
+### 复制
+#### 分区备份
+kafka会将topic分区复制到多台mq server上，mq server的数量可配置。（可以针对单个topic来设置replication factor的数量）。在其他server上保存副本允许当某台server发生故障宕机后，仍然可以从其他server上存储的副本中获取信息。  
+
+复制针对的是topic分区。在kafka中，每个分区都有一个leader和零或多个follower。leader加上follower的数量构成了replication factor。所有的写操作都会针对leader分区，而读操作则是可以针对leader或follower分区。通常情况下，分区比broker要多，leader分区分布在broker中。follower分区上的日志和leader分区上的日志都相同，offset和日志内容都相同（在特定时间点，leader尾部可能有一些尚未被复制到follower的消息）。  
+
+follower从leader分区消息消息，就像一个普通的消费者一样，并且将从leader处消费的消息追加到自己分区的尾部。  
+
+#### broker节点的活跃状态定义
+就像大多数的分布式系统一样，自动的故障容灾需要精确定义一个节点的“活跃”状态。在kafka中，存在一个节点单独来负责管理集群中broker的注册，该节点被称之为controller。broker的活跃状态需要满足如下要求：
+- broker需要和controller维持一个active session来接收常规的元数据更新
+- 作为follower的broker需要从leader处同步leader的写操作变动，从而保持分区数据和leader处相同
+
+对于使用zookeeper的集群，在broker节点初始化与zookeeper的连接会话时，会在zookeeper中创建一个节点，如果broker没能在`zookeeper.session.timeout.ms`时间内向zookeeper发送心跳包，那么broker就会丢失和zookeeper的会话，zookeeper中对应的节点也会被删除。controller会根据zookeeper watch注意到节点的删除，并且将该节点对应的broker标记为离线。  
+
+#### ISR
+满足上述“活跃”要求的节点会被成为"in sync"状态。而leader会跟踪那些处于“in sync”状态的副本，处于“in sync”状态的副本集合被称之为ISR(in sync replias，ISR中包含leader和follower).  
+
+如果ISR中的节点不再满足”活跃“对应的两条要求，那么该节点将会从ISR中被移除。例如，如果一个follower宕机，那么controller将会注意到zookeeper中节点的删除，并且将该broker中ISR中移除。
+
+另外，**如果一个节点仍然处于活跃状态，但是离同步leader的数据有很长的延迟，那么leader将会将该节点从ISR中移除**。延迟的最长时间通过`replica.lag.time.max.ms`来配置。如果在`replica.lag.time.max.ms`时间内副本没能通过leader到日志结尾的数据，那么副本节点将会从ISR中被移除。
+
+#### 消息提交的定义
+在某分区对应ISR中所有的副本都将消息追加到它们的log后，则可以认为该消息被提交。故而，消费者并无需担心分区的leader宕机后消息会丢失的问题，因为消息在提交前已经持久化到其分区副本中。  
+
+作为生产者，可以在发送消息时决定是否等待消息被提交，这需要在等待提交所带来的延迟和不等待提交所带来的消息丢失风险中进行权衡。是否等待提交取决于生产者的ack设置。  
+#### 最小写入副本数
+topic可以设置一个最小写入的副本数，通过配置`min.insync.replicas`，可以对最小写入副本数进行配置。即使消息已经同步到所有ISR副本后，如果同步数目小于该值（同步数目包含leader），消息也无法被视为提交
+
+> kafka保证一条消息只要被提交，只要有一个in-sync-replica处于活跃状态，那么消息就不会被丢失
+
+