网站的flash,网站被同行链接代替,深圳企业培训,seo职位1. CAP理论 1.1 Cosistency(一致性) 通过某个节点的写操作结果对后面通过其他节点的读操作可见。 如果更新数据后#xff0c;并发访问的情况下可立即感知该更新#xff0c;称为强一致性 如果允许之后部分或全部感知不到该更新#xff0c;称为弱一致性。 若在之后的一段时间并发访问的情况下可立即感知该更新称为强一致性 如果允许之后部分或全部感知不到该更新称为弱一致性。 若在之后的一段时间通常该时间不是固定的后一定可以感知到该更新称为最终一致性。 1.2 Availability(高可用性) 即是任何一个没有发生故障的节点必须在有限的时间内返回合理的结果不论是正确的还是错误的。 1.3 Partition tolerance分区容错性 部分节点宕机或者是无法与其他节点通信时各分区间还可以保持分部式系统的功能比如上海和北京两个网络分区当上海分区光纤或其他原因导致网络不通时北京上海两个分区之间不可通信但是最起码要保证北京的分区中的分布式系统功能可用。 1.4 CAP理论 分布式系统中一致性可用性分区容忍性最多只可同时满足两个但是一般分区容错性都是需要保障的因此很多时候都是在可用性和一致性之间做权衡。如下一幅图讲解了CP和AP的两种模式的具体表现形式 首先看CP模式N1和N2之间代表了网络通信C表示客户端X表示新写入的数据,Y表示旧数据当C向N2发起请求时由于N2与N1之间网络通信异常会导致N2不能同步到N1中的x,在保证一致性的情况下此时N2不会正常返回处理结果要么是等待网络连接成功将N1的Y获取过来保证数据一致要么系统出现错误这样的情况是不能保证高可用的但是保证了数据一致性。 AP模式下N1和N2之间代表了网络通信C表示客户端X表示新写入的数据,Y表示旧数据当C向N2发起请求时由于N2与N1之间网络通信异常会导致N2不能同步到N1中的X但是N2不会等待N1连接成功或是返回错误信息而是返回之前老的数据x,这样系统能够正常的运行但是数据的一致性并没有保证此时选择了系统的高可用方案。 1.5 一致性的方案 1.5.1 Master-slave(主从模式) RDBMS的读写分离即为典型的Master-slave方案 同步复制可保证强一只性但是会行影响性能因为Master必须要等待所有的salve都接收到到更新才能返回 异步复制提高可用性但是会降低一致性因为Master只需要自己写操作完成就立即返回同时向Slave进行复制这期间可能会出现某个或多个Slave由于网络或其他原因没有更新到数据造成数据不一致性。 1.5.2 WNR 主要用于去中心化P2P的分布式系统中。DynamoDB与Cassandra即采用此方案,N代表副本数W代表每次写操作要保证的最少写成功的副本数R代表每次读至少读取的副本数,当WRN时可保证每次读取的数据至少有一个副本具有最新的更新,多个写操作的顺序难以保证可能导致多副本间的写操作顺序不一致Dynamo通过向量时钟保证最终一致性。这里可以通过时间戳或者是自增主键之类的方式来保证过滤出读取的最新的数据。 1.5.3 Paxos及其变种 Google的ChubbyZookeeper的ZabRAFT等 2. Kafka的数据复制Replica Kafka提供了Replica保证了数据一致性 2.1 Replica 当某个Topic的replication-factor为N切N大于1时每个Partition都会有N个副本Replica,Replica的个数小于等于Broker数即对每个Partition而言每个Broker上只会有一个Replica因此可用Broker ID表示Replica所有Partition的所有Replica默认情况会均匀分布到所有Broker上如图 图中可以看到Broker中存的是Topic2的Partition0和Topic2的Partition2的Replica,但是在Broker2中却存了Topic2的Partition1和Topic2的Partition0的Replica所以默认的Partition都是分布在集群节点上的replica也一样。这就可以保证到某个节点挂掉之后其他的节点中保存的replica仍然可以向消费者推送或被拉取消息保证消息不丢失。 注意 假如当前我们搭建了三个Broker的集群但是我此时指定4个Replica时会出现org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 4 larger than available brokers: 3异常如图 2.2 Data Replication数据复制要解决的问题 2.2.1 如何Propagate备份消息 如下图 当producer想leader节点发送消息时其余follower节点个人理解跟slave类似将会如其他mq的consumer一样去从主节点的topic中将数据拉取或被推送到自身节点中。这样当leader节点挂掉之后consumer访问集群时仍然可以从其他的follower中获取到最新数据防止了数据丢失。 2.2.2 何时Commit ISR: Leader会维护一个与其基本保持同步的Replica列表该列表称为ISRin-sync Replica,如果一个Follower比Leader落后太多或者超过一定时间未发起数据复制请求则Leader将其从ISR中移除,当ISR中所有Replica都向Leader发送ACK时Leader即Commit告诉Producer消息发送成功。 Commit策略 1. 在Server中配置 replica.lag.time.max.ms默认100000最大未发起数据复制请求的时间。 replica.lag.max.messages最大落后消息数根据自身需要配置 2. Topic配置 min.insync.replicas1 ISR列表最小个数默认1只有当request.required.acks为-1时才生效如果ISR中的副本数少于min.insync.replicas配置的数量时客户端会返回异常org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。 3. Produce配置 request.required.acks1默认为1roducer发送数据到leaderleader写本地日志成功返回客户端成功此时ISR中的副本还没有来得及拉取该消息leader就宕机了那么此次发送的消息就会丢失当为-1时当producer设置request.required.acks为-1时min.insync.replicas指定replicas的最小数目必须确认每一个repica的写数据都是成功的如果这个数目没有达到producer会产生异常。 2.2.3 如何处理Replica恢复 如图 1. 可以看到SR{A,B,C},Leader(A)节点中存在m1,m2,m3三条消息F(B)存在m1,m2两条消息fc只存在m1一消息所以这里只会提交m1这条消息因为m2这条消息还没有在ISR中完成复制。它只会提交三个ISR中都存在的消息。 2. 当L(A)在将消息m2复制到B,C之后挂掉此时ISR中只有{B,C}B被选举成为新的主节点当m2,m1都存在于B,C节点中时B将会提交m1,m2两条消息不会提交m3消息。 3. 此时消息将都会发送到B节点上C节点同步了B节点中的新发的消息m4,m5之后将会提交m4,m5. 5.此时A节点连接集群成功或重启可以使用了它会从B节点中同步从m1,到m5的消息直到它的消息与B和C中的一致为止此时的Replica将会变成ISR{A,B,C},完成了Replica的恢复。这里我们发现m3并没有存在了这里并不是丢失了只是当没有主节点提交m3这条消息时它将会自动反馈到ProducerProducer会重试或做其他处理当重试成功后可能m3消息将会append到m5的后面所以consumer消费消息时我们保证的顺序性不是producer发送消息的顺序而是commit时的顺序。 2.2.4 如何处理Replica全部宕机 当ISR中的Replica全部宕机时可以通过如下方式处理 1. 等待ISR中任一Replica恢复并选它为Leader。 缺点等待时间较长降低可用性因为不能使用所有集群节点因此或ISR中的所有Replica都无法恢复或者数据丢失则该Partition将永不可用。 2. 选择第一个恢复的Replica为新的Leader无论它是否在ISR中。 缺点并未包含所有已被之前Leader Commit过的消息因为它不在之前的ISR中因此会造成数据丢失但是它提高了可用节点的范围可用性比较高。 原文 Kafka学习笔记3----Kafka的数据复制Replica与Failover 转载于:https://www.cnblogs.com/xiaoshen666/p/10867414.html
