第三章: Kafka原理剖析 下

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

CAP理论：分布式系统中，一致性、可用性、分区容忍性最多只可同时满足两个
一般分区容忍性都要求有保障，因此很多时候是在可用性与一致性之间做权衡

 

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

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

四、Data Replication要解决的问题
如何Propagate消息
何时Commit
如何处理Replica恢复
如何处理Replica全部宕机

五、如何Propagate消息 

六、何时Commit
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     https://blog.csdn.net/minicto/article/details/53925672

七、如何处理Replica恢复

 

 

八、如何处理Replica全部宕机
等待ISR中任一Replica恢复，并选它为Leader
等待时间较长，降低可用性
或ISR中的所有Replica都无法恢复或者数据丢失，则该Partition将永不可用
选择第一个恢复的Replica为新的Leader，无论它是否在ISR中
并未包含所有已被之前Leader Commit过的消息，因此会造成数据丢失
可用性较高