Kafka学习之路(一)Kafka的简介

一丶简介
1.1概述
Kafka是最初由Linkedin公司开发,是一个分布式,分区的,多副本的,多订阅者,基于zookeeper协调的分布式日志系统也可以当做MQ系统常见可以用web/nignx日志,访问日志,消息服务等等,Linkedin2010年贡献给了Apache基金会并成为定义开源项目,
主要应用场景是:日志收集系统和消息系统
Kafka主要设计目标如下:

1.一时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证时间的访问性能
2.高吞吐率,即使在非常廉价的商用机器上也能做到单机支持每秒100k条消息的传输
3.支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输
4.同时支持离线数据处理和实时数据处理
5.Scale out支持在线水平扩展

1.2 消息系统介绍

一个消费系统负责将数据从一个应用传递到另一个应用,应用只需要关注数据,无需关注数据在两个或多个应用间是如何传递的,分布式消息传递基于可靠的消息队列,在客户端应用和消息系统之间异步传递消息,有两种主要的消息传递模式:点对点传递模式,发布-订阅模式
, 大部分的消息系统选用发布-订阅模式,Kafka就是一种发布-订阅模式

1.3点对点消息传递模式
在点对点消息系统中,消息持久化到一个队列中,此时,将有一个或多个消费者队列中,此时,将有一个或多个消费者数据,也能保证数据处理顺序,这种架构描述适示意图如下:

生产者发送一条消息到queue,另有一个消费者能收到
1.4发布-订阅消息传递模式
在发布-订阅消息系统中,消息被持久化到一个topic中,与点对点消息系统不同的是,消费者可以订阅一个或者多个topic,消费者可以消费topic中所有的数据,同一条数据可以被多个消费者消费,数据被消费后不会立马删除,发布-订阅消息系统中,消息的生产者称为发布者,消费者称为订阅者,该模式示例图如下:

发布者发送到topic的消息,只有订阅了topic的订阅者才会收到消息
二丶Kafka的有点
2.1解耦

在项目启动之初来预测将来项目碰到什么需求,是极其困难的,消息系统在处理过程中插入了一个隐含的,基于数据的接口层,两边的处理过程都要实现这一接口,这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束,

2.2冗余(副本)

有些情况下,处理数据的过程会失败,除非数据被持久化,否则将赵成丢失,消息队列把数据进行持久化知道他们已经被完全处理,通过这一方式规避了数据丢失风险,许多消息队列采用的"插入-获取-删除"范式中,在吧一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经处理完毕,从而确保你的数据被安全的保存直到你使用完毕

2.3扩展性

因为消息队列解耦了你的处理过程,所以增大消息入队和处理的评率是很容易的,只要另外增加处理过程即可,不需要改变代码,不需要调节参数,扩展就像调大电力按钮一样简单

2.4灵活性&峰值处理能力

在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流浪并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费,使用消息队列能够是关键组件顶住突发的访问压力,而不是因为突发的超负荷的请求而完全崩溃

2.5可恢复性

系统的一部分组件失效时,不会影响整个系统,消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理

2.6顺序保证

在大多使用场景下,数据处理的顺序都很重要,大部分消息队列很来就是排序的,并且能保证数据会按照特定的顺序来处理,Kafka保证一个Partition内的消息有序性格

2.7缓冲

在任何重要的系统中,都会有需要不同的处理时间元素,列如,加载一张图片比应用过滤花费更少的时间,消息队列通过一个缓冲层来帮助任务最高效率的执行-------写入队列的处理会尽可能的快速,该缓冲有助于控制和优化数据流经过系统的速度

2.8异步通信

很多时候,用户不想也不需要立即处理消息,消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它,想向队列中放入多少消息就放多少,然后在需要的时候再去处理他们

三 丶常用的MessageQueue对比
3.1 RabbitMq

RabbitMQ是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP,SMTP,STOMP,也正因如此,它非常重量级,更适合于企业及的开发,同时实现了Broker构架,这意味着消息在发送客户端时现在中心队列排列,对路由.负载均衡或者数据层持久化都有很好的支持

3.2Redis

Redis是一个基于Key-Value对的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用,对于RabbitMQ和Redis的入列和出队操作,各执行100万次,每10万次记录一次执行时间,测试数据区分为128Betys,512Bytes,1k和10k四种不同大小数据的数据,实验证表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10k,redis则慢的无法容忍;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ
的出队性能则低于Redis,

3.3 ZeroMQ

ZeroMQ号称最快的消息队列系统,尤其针对大吞吐量的需求场景,ZeroMQ能够实现RabbitMQ不擅长的高级/复制的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用程序将扮演这服务器角色,你只需要简单地引用ZeroMQ程序库,可以使用NuGet安装,然后你就可以愉快的在应用之间发消息了,但是ZeroMQ仅提供非持久的队列,也就是说如果宕机，数据将会丢失,其中,Twitter的Storm0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输(Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块).

3.4ActveMQ

ActiveMQ是Apache下的一个子项目,类似于ZeroMQ,它能够以代理人和点对点的技术实现队列,同时类似于RabbitMQ,它少量代码就可以高效的实现高级应用场景

3.5Kafka/jafka

Kafka是Apache下的一个子项目,是一个高性能跨语言分布式/订阅消息队列系统,而Jafka之上孵化而来的,既Kafka的一个升级版,具有以下特性:快速持久化,可以在O(1)的系统开销下进行消息持久化;高吞吐,在一条普通的服务器上即可达到10w/s的吞吐速率;完全的分布式系统,Broker,Producer,Consumer都原生自动支持分布式,自动实现负载均衡;支持Hadoop数据并行加载,对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案,Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理,Apache
Kafka相对于ActiveMQ是一个非常轻量级的消息系统,除了性能非常好之外,还是一个工作环境良好的分布式系统,

四丶Kafka中的数据术语解释
4.1概述
在深入理解Kafka之前,先介绍一下Kafka中的术语,下图展示了Kafka的相关数据以及之间的关系:

上图中一个topic配置了3个partition,Partition1有两个offset:0和1,Partition2有4个offset,Partition3个offset,副本的id和副本所在的机器的id恰好相同
如果一个topic的副本数为3,那么Kafa将在集群中为每个partition穿件3个相同的副本,集群中的每个broke存储一个或者多个partition.多个produce和consumer可同时产生和消费数据
4.2broker

Kafka集群包含一个或多个服务器,服务器节点称为broker,
broker存储topic的数据,如果某topic有N个partition,集群有N个broker,那么每个broker存储topic存储topic的一个partition
如果某topic有N个partition,集群有?(N+M)个broker,那么其中有N个broker存储该topic的一个partition,剩下的M个broker不存储topic的partition数据
如果某topic有N个partition,集群中broker数目少于N个,那么一个broker存储该topic的一个或多个partition,在实际生产环境中,尽量避免这种情况的发生,这种情况容易导致Kafka集群数据不均衡

4.3Topic

每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic(物理上不同Topic的消息分开存储,逻辑上一个Topic的消息虽然保存一个或多个broker上但用户只需指定消息的Topic的小子虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关系数据存在何处)类似于数据库的表名

4.3Partition

topic中的数据分割为一个或多个partition,每个topic至少有一个partition,每个partition中的数据使用多个segment文件存储,partition中的数据有序的,不同partition间的数据丢失了数据的顺序,如果topic有多个partiton,消费数据时就不能保证数据顺序,在需要严格保证消息的消费顺序的场景下,需要将partition数目设为1,

4.4Producer

生产者即数据的发布者,该角色将消息发布到Kafka的topic中.broker接收到生产者发送的消息后,broker将该消息追加到当前用于追加数据的segment文件中,生产者发送的消息,存储到一个partition中,生产者也可以指定数据存储的partition

4.5Consumer

消费者可以从briker中读取数据,消费者可以消费多个topic中的数据

4.6Consumer Group

每个Consumer属于一个特定的Consumer Grop(可为每个Consumer指定 group name,如不指定group
name则属于默认的group),

4.7Learder

每个partition有多个副本.其中有且仅有一个作为Leader,Leader是当前负责数据的书写的partition

4.8Follower
Follower跟随Leader,所有写请求都通过Leader路由,数据便跟会广播给所有Follower,Follower与Leader保持数据同步,如果Leader失效,则从Follower中选举出一个新的Leader,当Follower与Leader挂掉,卡住或者同步太慢,leader会把这个follower从"in sync replicas"(ISR)列表中删除,重新创建一个Follower,