Kafka HA Kafka一致性重要机制之ISR

Consistency
  通过某个节点的写操作结果对后面通过其它节点的读操作可见
  如果更新数据后，并发访问情况下可立即感知该更新，称为强一致性
  如果允许之后部分或者全部感知不到该更新，称为弱一致性
  若在之后的一段时间（通常该时间不固定）后，一定可以感知该更新，称为最终一致性
Availability
  任何一个没有发生故障的节点必须在有限的时间内返回合理的结果
Partition tolerance
  部分节点宕机或者无法与其它节点通信时，各分区间还可保持分布式系统的功能 

Master-slave
  RDBMS的读写分离即为典型的Master-slave方案
  同步复制可保证强一致性但会影响可用性
  异步复制可提供高可用性但会降低一致性
WNR
  主要用于去中心化（ P2P）的分布式系统中。 DynamoDB与Cassandra即采用此方案
  N代表副本数， W代表每次写操作要保证的最少写成功的副本数， R代表每次读至少读取的副本数
  当W+R>N时，可保证每次读取的数据至少有一个副本具有最新的更新
  多个写操作的顺序难以保证，可能导致多副本间的写操作顺序不一致， Dynamo通过向量时钟保证最终一致性
Paxos及其变种
  Google的Chubby， Zookeeper的Zab， RAFT等 

当某个Topic的replication-factor为N且N大于1时，每个Partition都会有N个副本（ Replica）
Replica的个数小于等于Broker数，即对每个Partition而言每个Broker上只会有一个Replica，因此可用Broker ID表示Replica
所有Partition的所有Replica默认情况会均匀分布到所有Broker上 

如何Propagate消息
何时Commit
如何处理Replica恢复
如何处理Replica全部宕机 

ISR
Leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR（ in-sync Replica）
如果一个Follower比Leader落后太多，或者超过一定时间未发起数据复制请求，则Leader将其从ISR中移除
当ISR中所有Replica都向Leader发送ACK时， Leader即Commit


Commit策略
  Server配置
    replica.lag.time.max.ms=10000
    replica.lag.max.messages=4000
  Topic配置
    min.insync.replicas=1
    Producer配置
    request.required.acks=0