Kafka介绍

kafka是一个分布式消息系统


kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer


此外kafka集群有多个kafka实例组成，每个实例(server)成为broker


 一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)每个partition在存储层面是append log文件。


任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量)


offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存


储offset，因为在kafka中几乎不允许对消息进行“随机读写”。


以上总结为  一个集群有多个Kafka实例,实例就是broker 一个实例里有多个Topic,一个Topic里有多个partition,一个Partition里有多条消息


partition里的消息,即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时间之后删除;比如log文件保留2天,那么两天后,文件会被清除,无论其中的消息是否被消费.kafka通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘IO开支.


 kafka集群几乎不需要维护任何consumer和producer状态信息,这些信息有zookeeper保存;


因此producer和consumer的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响.
 
partitions的设计目的有多个.最根本原因是kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到


单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存,每个server(kafka实例)负责partitions中消息的读写操,作可以将


一个topic切分多任意多个partitions,来消息保存/消费的效


率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.(具体原理参见下文)


以上总结为 消息是存储在日志文件里的,所以通过分区的形式,一个分区用一个broker保存,不过这样只是一个方案吧,也可以一个实例保存


多个分区吧?




kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性.
 
    基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为"leader";leader负责所有的读写操


作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可..由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定.


 Producers
    Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.
 
    Consumers
    本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.


    如果所有的consumer都具有相同的group,这种情况和queue模式很像;消息将会在consumers之间负载均衡.


    如果所有的consumer都具有不同的group,那这就是"发布-订阅";消息将会广播给所有的消费者.


    在kafka中,一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺序的.事实上,从Topic角度来说,


消息仍不是有序的.


 kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息
 
    Guarantees
    1) 发送到partitions中的消息将会按照它接收的顺序追加到日志中


    2) 对于消费者而言,它们消费消息的顺序和日志中消息顺序一致.


    3) 如果Topic的"replicationfactor"为N,那么允许N-1个kafka实例失效.


以上总结为partition的信息也可以被备份在多个实例,当承担leader责任的那个server挂了,就会有备份机成为新的leader,然后有一点需要注


意的是,一个partition对应一个consumer,所以才说,同一个group中不能有多于partition个数的consumer同时消费,比如说,partition有5


个,而consumer有6个,则多出一个consumer没有对应的partition消息让他读


设计原理
    kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力.
 
    1、持久性
    kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎


没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了


减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用


的次数.


2、性能
    需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的


技巧;对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker;对于consumer端也是一样,批量


fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,似乎有个sendfile系统调用可以潜在的提升网络IO


的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换. 其实对于


producer/consumer/broker三者而言,CPU的开支应该都不大,因此启用消息压缩机制是一个良好的策略;压缩需要消耗少量的CPU资


源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.
 
    3、生产者
 
   负载均衡: producer将会和Topic下所有partition leader保持socket连接;消息由producer直接通过socket发送到broker,中间


不会经过任何"路由层".事实上,消息被路由到哪个partition上,有producer客户端决定.比如可以采用"random""key-hash""轮


询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的.
 
    其中partition leader的位置(host:port)注册在zookeeper中,producer作为zookeeper client,已经注册了watch用来监听


partition leader的变更事件.
    
异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量


延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。
    
    4、消费者
    consumer端向broker发送"fetch"请求,并告知其获取消息的offset;此后consumer将会获得一定条数的消息;consumer端也可


以重置offset来重新消费消息.


 启动Kafka 

首先定位到zookeeper的bin目录下,在cmd下,直接输入zkServer.cmd启动zookeeper

然后定位到kafka的目录下如图,在cmd下输入.\bin\windows\kafka-server-start.bat   .\config\server.properties启动kafka