Kafka数据辅助和Failover

数据辅助与Failover

CAP理论(它具有一致性、可用性、分区容忍性)

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

一致性方案

1.Master-slave

》RDBMS的读写分离即为典型的Master-slave方案

》同步复制可保证强一致性但会影响可用性(等master确保将数据复制给全部的slave,slave才返回结果)

》异步复制可提供高可用性但会降低一致性

2.WNR

》主要用于去中心化(P2P)的分布式系统,DynameDB与Cassandra即采用此方案

》N代表副本数,W代表每次写操作要保证的最少写成功的副本数,R代表每次读至少读取的副本数

》当W+R>N时,可保证每次读取的数据至少有一个副本具有最新的更新

》多个写操作的顺序难以保证,可能导致多副本间的写操作顺序不一致,Dynamo通过向量时钟保证最终一致性

3.Paxos及其变种

》Google的Chubby,Zookeeper的Zab,RAFT等

Kafka是如何权衡CA的呢?

Replica

如:

当一个Patiton副本数超过Broker时,就会报错

Data Replication要解决的问题

1.如何Propagate(扩散)消息

2.何时Commit

3.如何处理Replica恢复

4.如何处理Replica全部宕机

1.如何Propagate(扩散)消息

以写入数据为例,Patiton分为leader和follower,follower周期性的向leader pull数据(和consumer相似)。

在读取数据时,与数据库读写分离不一样,follower并不参与读取操作,读取只和leader有关。

为了提高性能,每个Follower在接收到数据后就立马向Leader发送ACK,而非等到数据写入Log中。因此,对于已经commit的消息,Kafka只能保证它被存于多个Replica的内存中,而不能保证它们被持久化到磁盘中,也就不能完全保证异常发生后该条消息一定能被Consumer消费。但考虑到这种场景非常少见,可以认为这种方式在性能和数据持久化上做了一个比较好的平衡。在将来的版本中,Kafka会考虑提供更高的持久性。

2.何时Commit

由上图可知,leader数据发送给follower既不是同步通信也不是异步通信,而是在一致性和可用性做了动态的平衡

3.如何处理Replica恢复

4.如何处理Replica全部宕机

等待ISR中任一Replica恢复,并选它为Leader

》等待时间较长,降低可用性

》或ISR中的所有Replica都无法恢复或者数据丢失,则该Patition将永不可用

选择第一个恢复的Replica为新的Leader,无论它是否在ISR中

》可能会有数据丢失

》可用性较高

时间: 08-17

Kafka数据辅助和Failover的相关文章

kafka数据祸福和failover

k CAP帽子理论. consistency:一致性 Availability:可用性 partition tolerance:分区容忍型 CA :mysql oracle(抛弃了网络分区) CP:hbase redis mongodb(抛弃了可用性) AP:cassandra simpleDB(抛弃了强一致性,采用弱一致性或者最终一致性,不定时一致性) 一致性的方案 master-slave(hadoop) WNR 读取后还得判断哪个数据是最新的.常用做法(版本号或者时间戳) 平时读取数据是从

kafka数据迁移

kafka数据迁移操作流程: 此次数据迁移主要是针对Isr自动同步异常,而进行手动干预的操作. 具体的故障截图如下: 一.确认同步异常的topic和Isr数目 ./kafka-topics.sh --under-replicated-partitions --describe --zookeeper IP:2181 二.创建文件/tmp/topics-to-move.json vim /tmp/topics-to-move.json 复制这些topic,并写成如下格式的文件, 命名为 topic

flume 读取kafka 数据

本文介绍flume读取kafka数据的方法 代码: /******************************************************************************* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements.  See the NOTICE file * distributed with

2016年大数据Spark“蘑菇云”行动之spark streaming消费flume采集的kafka数据Directf方式

王家林老师的课程:2016年大数据Spark"蘑菇云"行动之spark streaming消费flume采集的kafka数据Directf方式作业.     一.基本背景 Spark-Streaming获取kafka数据的两种方式Receiver与Direct的方式,本文介绍Direct的方式.具体的流程是这样的: 1.Direct方式是直接连接到kafka的节点上获取数据了. 2.基于Direct的方式:周期性地查询Kafka,来获得每个topic+partition的最新的offs

spark streaming从指定offset处消费Kafka数据

spark streaming从指定offset处消费Kafka数据 2017-06-13 15:19 770人阅读 评论(2) 收藏 举报 分类: spark(5) 原文地址:http://blog.csdn.net/high2011/article/details/53706446 首先很感谢原文作者,看到这篇文章我少走了很多弯路,转载此文章是为了保留一份供复习用,请大家支持原作者,移步到上面的连接去看,谢谢 一.情景:当Spark streaming程序意外退出时,数据仍然再往Kafka中

java spark-streaming接收TCP/Kafka数据

本文将展示 1.如何使用spark-streaming接入TCP数据并进行过滤: 2.如何使用spark-streaming接入TCP数据并进行wordcount: 内容如下: 1.使用maven,先解决pom依赖 <dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-streaming-kafka_2.10</artifactId> <version>1

Spark Streaming 读取 Kafka 数据的两种方式

在Spark1.3之前,默认的Spark接收Kafka数据的方式是基于Receiver的,在这之后的版本里,推出了Direct Approach,现在整理一下两种方式的异同. 1. Receiver-based Approach val kafkaStream = KafkaUtils.createDstream(ssc, [zk], [consumer group id], [per-topic,partitions] ) 2. Direct Approach (No Receivers) v

kafka数据接口定义最佳实践

1 上游业务系统向kakfa推送的数据全部应为 字符串类型,使用的时候 转换成需要的类型,保证数据可以类型转换2 为了便于后续 kafka数据校对,建议把推送数据来自的数据库主键id,也一起推送过来(一般数据推送流程:业务过程 --> 插入DB(返回主键id) --> 推送kafka) 3 所有金额涉及到到计算全部使用 decimal 类型,不要使用double 4 小数的位数需要明确好 原文地址:https://www.cnblogs.com/wooluwalker/p/12168066.h

Apche Kafka 的生与死 – failover 机制详解

Kafka 作为 high throughput 的消息中间件,以其性能,简单和稳定性,成为当前实时流处理框架中的主流的基础组件. 当然在使用 Kafka 中也碰到不少问题,尤其是 failover 的问题,常常给大家带来不少困扰和麻烦. 所以在梳理完 kafka 源码的基础上,尽量用通俗易懂的方式,把 Kafka 发生 failover 时的机制解释清楚,让大家在使用和运维中,做到心中有数. 如果对 kafka 不了解的,可以先参考https://kafka.apache.org/08/des